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

SLE structure - OO violation?

Expand Messages
  • Tom
    There seems to be an assumption in the SLE threads that the communications in an SLE have to conform to a star network with a single hub and all the
    Message 1 of 2 , Sep 8, 2010
    • 0 Attachment
      There seems to be an assumption in the SLE threads that the communications in an SLE have to conform to a star network with a single hub and all the development teams at the edges.

      That may be the way it is in many SLEs, but a more productive way to
      look at it as a general network, in which each team is related to a small set of other teams as either a customer or a supplier (ala Eric Evans' discussion of team relationships in "Domain Driven Design").

      This shifts the focus away from a global architecture to specific interfaces and contracts. Sure, there will be systems and network groups that provide services to most or all of the teams, but the contracts could still be very specific in terms of interfaces and service level agreements. This is the way we organize heterogeneous networks, federated databases, web services, etc.

      Now that I think of it, it's the same sort of structural issue we get into when we're considering using frameworks (as opposed to libraries) to develop applications (I seem to remember Ron having some strong opinions on that - which I pretty much share).

      In fact, it's really OO 101 (hmm - that looks binary): we shun architectures with a single centralized "master" object and a set of "slaves" whose every communication passes through the master, although there was a time when this was the norm for Successful Large Systems....

      In all these cases it's the illusion of control (as in cmd&ctl) that makes people build star/hierarchical structures. When the actual necessary flows (of messages, goods, etc.) are analyzed, a distributed holographic network almost always makes more sense and is more robust.

      Try discussing that in an environment where CEOs make 200 times as much as code monkeys.
    • Adam Sroka
      Sure. You could even take that a step further. A modern, scalable application has numerous parallel threads that operate with little or no shared state. It is
      Message 2 of 2 , Sep 8, 2010
      • 0 Attachment
        Sure. You could even take that a step further. A modern, scalable
        application has numerous parallel threads that operate with little or no
        shared state. It is feasible that an "SLE" could operate that way, with many
        independent lines of business that had their own customers and employed
        their own small, cross-functional software teams. In fact, many
        organizations do function this way.

        On Wed, Sep 8, 2010 at 2:36 PM, Tom <rossentj@...> wrote:

        >
        >
        > There seems to be an assumption in the SLE threads that the communications
        > in an SLE have to conform to a star network with a single hub and all the
        > development teams at the edges.
        >
        > That may be the way it is in many SLEs, but a more productive way to
        > look at it as a general network, in which each team is related to a small
        > set of other teams as either a customer or a supplier (ala Eric Evans'
        > discussion of team relationships in "Domain Driven Design").
        >
        > This shifts the focus away from a global architecture to specific
        > interfaces and contracts. Sure, there will be systems and network groups
        > that provide services to most or all of the teams, but the contracts could
        > still be very specific in terms of interfaces and service level agreements.
        > This is the way we organize heterogeneous networks, federated databases, web
        > services, etc.
        >
        > Now that I think of it, it's the same sort of structural issue we get into
        > when we're considering using frameworks (as opposed to libraries) to develop
        > applications (I seem to remember Ron having some strong opinions on that -
        > which I pretty much share).
        >
        > In fact, it's really OO 101 (hmm - that looks binary): we shun
        > architectures with a single centralized "master" object and a set of
        > "slaves" whose every communication passes through the master, although there
        > was a time when this was the norm for Successful Large Systems....
        >
        > In all these cases it's the illusion of control (as in cmd&ctl) that makes
        > people build star/hierarchical structures. When the actual necessary flows
        > (of messages, goods, etc.) are analyzed, a distributed holographic network
        > almost always makes more sense and is more robust.
        >
        > Try discussing that in an environment where CEOs make 200 times as much as
        > code monkeys.
        >
        >
        >


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.