Twitter Updates

    follow me on Twitter

    Feeds & Email

    • Feeds and Lists
    • FeedBlitz
      Enter your Email

      Powered by FeedBlitz
    Blog powered by Typepad


    « Differences Between 'What' & 'How' in Enterprise Architecture | Main | Want Fries With Your Change(s)? »


    Muli Koppel

    Hi Bob

    I would like to take B' side in this discussion and add yet another concern: what if A's application is down (for whatever reason), or ill performing exactly when B needs A's information?

    And as for the nice idea of having an API returning historical changes made to A's information, well, that's might be ok for bespoke apps, but harder to implement for COTS packages.

    And when you increase the number of participants from two (A & B) to a thousand…

    If you design the Information & SOA architecture of an Enterprise with a pessimistic, "design for failures" approach, I think you should assume two things:
    1. B concerns are right and A is never to be trusted for availability and performance.
    2. It is impractical to ask the 1000 As to provide a history API.

    Historically, these issues were solved with replication and all the Bs creating their own aggregations and whatever other data manipulation on A's data – as you described. But that has led to other operational issues and data stewardship issues – as you mentioned.

    Which is why I am advocating for the man in the middle approach, or - an information hub (may I link back to my "always-on" post without being accused of self-promotion?).

    All the best

    Bob McIlree


    Yes, feel free to trackback to your post and thank you for asking as some of our blogging breathren do not.

    B's concerns are warranted and I didn't address certain major operational issues that A faces such as availability, failover, hot standby, etc., which I assume would be present in an approach like this. And yes, COTS is a whole different story that I will talk about today in a followup.

    The conundrum problems like this present to architects is that while we assume never to trust A's, if A's are SSoRs, then all of the B's must assume that their stored data is never correct. Also, as the amount of B's multiply, the risk that the values B's hold that are not only out-of-synch with A, but with each other as well becomes problematic.

    You have given me a lot to ponder here my friend. Thanks!


    The comments to this entry are closed.