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

Re: Schema Compatibility

Expand Messages
  • chandrakant_g
    Excellent discussion - i would love to hear the different viewpoints. In my earlier project, we ran against this situation all the time. We only used to take
    Message 1 of 17 , Jun 30, 2003
    • 0 Attachment
      Excellent discussion - i would love to hear the different viewpoints.
      In my earlier project, we ran against this situation all the time. We
      only used to take on stored procedure changes though. So for stored
      procedure changes (those that had impacts, like an argument change),
      we changed the name of the proc invoked in the newer application
      from 'sp_xxx' to 'sp_xxx_v1' and released it. The 'sp_xxx' was
      finally phased out after a couple of releases.
      Would love to hear solutions for table/column changes...


      --- In agileDatabases@yahoogroups.com, "psadalage" <psadalage@y...>
      wrote:
      > how many times have people run into a situation where they had to
      > run different releases of the application against the same
      database.
      > Or atleast make the database schema compatable with muliple
      releases
      > of the application.
      >
      > If you have, what are the most common approaches taken and problems
      > encountered.
      >
      > Pramod
    • Marc Hamann
      I don t know how many of you also follow the [dm-discuss] list (the dm stands for data management), or followed the flame war that raged for past couple of
      Message 2 of 17 , Jul 4, 2003
      • 0 Attachment
        I don't know how many of you also follow the [dm-discuss] list (the dm
        stands for data management), or followed the flame war that raged for past
        couple of weeks (DM vs. agile), but I must say that it provoked a major
        re-assessment for me of the "mission" of THIS list.

        As a preface, I should say that for most of my career in IT, I have
        considered myself a "database developer" with significant responsibilities
        for data management as well. In the last few years, I have tended to
        consider myself a "data application developer" and am a committed
        Agilist. So I have sympathies in both camps.

        The thesis of this list seems to be: if we (data managers and application
        developers) could just stop fighting and blaming each other, we could use
        each others skills to succeed in producing business value for our
        customers/employers. To this end we must develop techniques to work
        together and make both database and application "agile". Scott, Pramod and
        others are blazing the way to developing these techniques.

        Now I whole-heartedly support this goal, and clearly this is working in
        practice in some contexts, but my reflections upon the flame-fest have me
        wondering if it isn't possible that, in the general case, it is overly
        optimistic to expect a synthesis between the two.

        The reason is that, though both sides believe that they are producing
        business value, the have radically different beliefs about how to provide it.

        The data managers (and my "data manager angel") believe that "data is
        king", i.e. that the business value resides solely in the quality and
        correctness of the data. From a data point of view, applications come and
        go, but the data schema has to remain valid forever.
        Thus the solution is to create the "correct" schema (well-normalized,
        well-constrained, logic contained in the schema, etc.) and protect it from
        the application with gate-keepers (stored procedures, triggers, etc.) In a
        sense, to be a DM is to be instinctively committed to BDUF.

        The application developers (and my "application developer angel") believe
        that business value is provided by giving people "smart tools" that are
        easy to use and which simplify business processes. Good data is important,
        but if people don't actually enter it, because the tool is too cumbersome,
        or insufficiently useful to their daily activities, you won't actually
        collect any. The risk of change is managed by being able to refactor (or
        simply reprogram) the application as requirements change.

        Now, this isn't necessarily an insurmountable divide, but if you look at
        what happens when you build your typical n-tier application, the problem
        becomes clearer. For the sake of performance and application flexibility,
        since database calls are expensive, you must duplicate in the middle
        tier(s) a lot of the logic that the DM wants strictly in the DB. From the
        DM point of view this isn't necessarily a problem; if the data is locked
        down twice so much the better, so long as it is locked down definitively at
        the DB. From the agile developers point of view, this is a major waste of
        energy and increase in complexity.

        The response to this dilemma from each community seems to be to predict the
        demise of the other. The DMs say "soon there won't be any application,
        just meta-data". The developers say "soon the relational model will die
        and we will just have persistence frameworks."

        I don't think either is endangered (or perhaps, given the IT slump, they
        are both equally endangered ;-) ), and I don't see how, barring a major
        technological advance, the _aims_ of the two groups can be systemically
        reconciled, without asking one or the other to "come over" to the other side.

        A barrage of thoughtful replies to this dilemma might soothe this "dark
        night of the Agile DB soul". ;-)

        Thanks!

        Marc
      • bhagyashree prabhakar
        Hi, I am neither a hardened application developer nor a Data Manager by the word. I believe there is no definite solution to this situation. If we are
        Message 3 of 17 , Jul 5, 2003
        • 0 Attachment
          Hi,
          I am neither a hardened "application developer" nor a
          "Data Manager" by the word.

          I believe there is no definite solution to this
          situation. If we are very sure that the same database
          product will be used throughout the life of the
          application, then keeping the business logic at the
          database level (as stored procedures, triggers) will
          ensure better performance. Duplicating this logic at
          the application level can be avoided. However, if we
          ever intend to change the database product we might
          have to redo the procedures/triggers.
          The other point is the expertise of team members. If
          most of them are application developers, the project
          might be better off with business logic left at the
          application level, considering frequent changes and
          refactoring that may be required. The complexity of
          the business logic will dictate where it will be kept
          in such situations.
          Simple validations like max. character length must
          definitely be kept at the application level. It makes
          no sense to send the field until the database and
          carry back an exception through all the n-tiers.

          -Bhagya

          --- Marc Hamann <marc@...> wrote:
          >
          > I don't know how many of you also follow the
          > [dm-discuss] list (the dm
          > stands for data management), or followed the flame
          > war that raged for past
          > couple of weeks (DM vs. agile), but I must say that
          > it provoked a major
          > re-assessment for me of the "mission" of THIS list.
          >
          > As a preface, I should say that for most of my
          > career in IT, I have
          > considered myself a "database developer" with
          > significant responsibilities
          > for data management as well. In the last few years,
          > I have tended to
          > consider myself a "data application developer" and
          > am a committed
          > Agilist. So I have sympathies in both camps.
          >
          > The thesis of this list seems to be: if we (data
          > managers and application
          > developers) could just stop fighting and blaming
          > each other, we could use
          > each others skills to succeed in producing business
          > value for our
          > customers/employers. To this end we must develop
          > techniques to work
          > together and make both database and application
          > "agile". Scott, Pramod and
          > others are blazing the way to developing these
          > techniques.
          >
          > Now I whole-heartedly support this goal, and clearly
          > this is working in
          > practice in some contexts, but my reflections upon
          > the flame-fest have me
          > wondering if it isn't possible that, in the general
          > case, it is overly
          > optimistic to expect a synthesis between the two.
          >
          > The reason is that, though both sides believe that
          > they are producing
          > business value, the have radically different beliefs
          > about how to provide it.
          >
          > The data managers (and my "data manager angel")
          > believe that "data is
          > king", i.e. that the business value resides solely
          > in the quality and
          > correctness of the data. From a data point of view,
          > applications come and
          > go, but the data schema has to remain valid forever.
          > Thus the solution is to create the "correct" schema
          > (well-normalized,
          > well-constrained, logic contained in the schema,
          > etc.) and protect it from
          > the application with gate-keepers (stored
          > procedures, triggers, etc.) In a
          > sense, to be a DM is to be instinctively committed
          > to BDUF.
          >
          > The application developers (and my "application
          > developer angel") believe
          > that business value is provided by giving people
          > "smart tools" that are
          > easy to use and which simplify business processes.
          > Good data is important,
          > but if people don't actually enter it, because the
          > tool is too cumbersome,
          > or insufficiently useful to their daily activities,
          > you won't actually
          > collect any. The risk of change is managed by being
          > able to refactor (or
          > simply reprogram) the application as requirements
          > change.
          >
          > Now, this isn't necessarily an insurmountable
          > divide, but if you look at
          > what happens when you build your typical n-tier
          > application, the problem
          > becomes clearer. For the sake of performance and
          > application flexibility,
          > since database calls are expensive, you must
          > duplicate in the middle
          > tier(s) a lot of the logic that the DM wants
          > strictly in the DB. From the
          > DM point of view this isn't necessarily a problem;
          > if the data is locked
          > down twice so much the better, so long as it is
          > locked down definitively at
          > the DB. From the agile developers point of view,
          > this is a major waste of
          > energy and increase in complexity.
          >
          > The response to this dilemma from each community
          > seems to be to predict the
          > demise of the other. The DMs say "soon there won't
          > be any application,
          > just meta-data". The developers say "soon the
          > relational model will die
          > and we will just have persistence frameworks."
          >
          > I don't think either is endangered (or perhaps,
          > given the IT slump, they
          > are both equally endangered ;-) ), and I don't see
          > how, barring a major
          > technological advance, the _aims_ of the two groups
          > can be systemically
          > reconciled, without asking one or the other to "come
          > over" to the other side.
          >
          > A barrage of thoughtful replies to this dilemma
          > might soothe this "dark
          > night of the Agile DB soul". ;-)
          >
          > Thanks!
          >
          > Marc
          >
          >
          >


          __________________________________
          Do you Yahoo!?
          SBC Yahoo! DSL - Now only $29.95 per month!
          http://sbc.yahoo.com
        • Scott W. Ambler
          ... Exactly. See www.agiledata.org/essays/referentialIntegrity.html which discusses some of the options that you have for placing business logic and RI logic.
          Message 4 of 17 , Jul 5, 2003
          • 0 Attachment
            At 02:52 AM 7/5/2003 -0700, you wrote:
            >Hi,
            >I am neither a hardened "application developer" nor a
            >"Data Manager" by the word.
            >
            >I believe there is no definite solution to this
            >situation.

            Exactly. See www.agiledata.org/essays/referentialIntegrity.html which
            discusses some of the options that you have for placing business logic and
            RI logic.



            > If we are very sure that the same database
            >product will be used throughout the life of the
            >application,

            But there are often several databases and several applications....


            > then keeping the business logic at the
            >database level (as stored procedures, triggers) will
            >ensure better performance. Duplicating this logic at
            >the application level can be avoided. However, if we
            >ever intend to change the database product we might
            >have to redo the procedures/triggers.

            Yes, although the same thing can be said if you change the application
            development product too.

            You also have an issue if there are multiple databases involved, something
            that is often conveniently forgotten about by the folks that always tell
            you that you need to put all the logic in the db.



            >The other point is the expertise of team members. If
            >most of them are application developers, the project
            >might be better off with business logic left at the
            >application level, considering frequent changes and
            >refactoring that may be required. The complexity of
            >the business logic will dictate where it will be kept
            >in such situations.

            Good point. And vice versa of course.


            >Simple validations like max. character length must
            >definitely be kept at the application level. It makes
            >no sense to send the field until the database and
            >carry back an exception through all the n-tiers.
            >
            >-Bhagya
            >
            ><snip>

            = Scott


            ====================================================
            Scott W. Ambler
            Senior Consultant, Ronin International, Inc.
            www.ronin-intl.com/company/scottAmbler.html

            www.agiledata.org
            www.agilemodeling.com
            www.ambysoft.com
            www.enterpriseunifiedprocess.info
            www.modelingstyle.info
            www.ronin-intl.com
          • Marc Hamann
            Thanks to Bhagya and Scott for the responses, but I think the essential point of my post has been skipped over. If you have already embraced the Agile approach
            Message 5 of 17 , Jul 6, 2003
            • 0 Attachment
              Thanks to Bhagya and Scott for the responses, but I think the essential
              point of my post has been skipped over.

              If you have already embraced the Agile approach to development (which
              suggests a development focus in the first place), then it is obvious that
              there is no definitive place to put the data logic; it will be decided by
              specific circumstances.

              But the database specialists DON'T necessarily start with this assumption;
              they often have a strong belief in a fixed "right way" to build databases.

              Given that, how can we expect them to cooperate with developers? Are we
              hoping that something will happen to them on the road to Damascus?

              The only way to build cooperation I know of is to align interests. If
              Agilists assume that one approach is right (let the circumstances decide)
              and the database team has another (everything in the database), how can we
              expect to build an understanding?

              Is it also possible that it isn't a case of one side being right and the
              other wrong, but that each is right based on their own responsibilities and
              goals?

              Marc

              At 06:49 AM 7/5/03, you wrote:
              >At 02:52 AM 7/5/2003 -0700, you wrote:
              > >Hi,
              > >I am neither a hardened "application developer" nor a
              > >"Data Manager" by the word.
              > >
              > >I believe there is no definite solution to this
              > >situation.
              >
              >Exactly. See www.agiledata.org/essays/referentialIntegrity.html which
              >discusses some of the options that you have for placing business logic and
              >RI logic.
              >
              >
              >
              > > If we are very sure that the same database
              > >product will be used throughout the life of the
              > >application,
              >
              >But there are often several databases and several applications....
              >
              >
              > > then keeping the business logic at the
              > >database level (as stored procedures, triggers) will
              > >ensure better performance. Duplicating this logic at
              > >the application level can be avoided. However, if we
              > >ever intend to change the database product we might
              > >have to redo the procedures/triggers.
              >
              >Yes, although the same thing can be said if you change the application
              >development product too.
              >
              >You also have an issue if there are multiple databases involved, something
              >that is often conveniently forgotten about by the folks that always tell
              >you that you need to put all the logic in the db.
              >
              >
              >
              > >The other point is the expertise of team members. If
              > >most of them are application developers, the project
              > >might be better off with business logic left at the
              > >application level, considering frequent changes and
              > >refactoring that may be required. The complexity of
              > >the business logic will dictate where it will be kept
              > >in such situations.
              >
              >Good point. And vice versa of course.
              >
              >
              > >Simple validations like max. character length must
              > >definitely be kept at the application level. It makes
              > >no sense to send the field until the database and
              > >carry back an exception through all the n-tiers.
              > >
              > >-Bhagya
              > >
              > ><snip>
              >
              >= Scott
              >
              >
              >====================================================
              >Scott W. Ambler
              >Senior Consultant, Ronin International, Inc.
              >www.ronin-intl.com/company/scottAmbler.html
              >
              >www.agiledata.org
              >www.agilemodeling.com
              >www.ambysoft.com
              >www.enterpriseunifiedprocess.info
              >www.modelingstyle.info
              >www.ronin-intl.com
              >
              >
              >
              >
              >To unsubscribe from this group, send an email to:
              >agileDatabases-unsubscribe@yahoogroups.com
              >
              >
              >
              >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            • Scott W. Ambler
              ... To be fair, many developers will start with the one right way themselves. ... It s spectacularly difficult. I m active on the data management mailing
              Message 6 of 17 , Jul 7, 2003
              • 0 Attachment
                At 12:16 AM 7/7/2003 -0400, Marc wrote:

                >Thanks to Bhagya and Scott for the responses, but I think the essential
                >point of my post has been skipped over.
                >
                >If you have already embraced the Agile approach to development (which
                >suggests a development focus in the first place), then it is obvious that
                >there is no definitive place to put the data logic; it will be decided by
                >specific circumstances.
                >
                >But the database specialists DON'T necessarily start with this assumption;
                >they often have a strong belief in a fixed "right way" to build databases.

                To be fair, many developers will start with the "one right way" themselves.



                >Given that, how can we expect them to cooperate with developers? Are we
                >hoping that something will happen to them on the road to Damascus?

                It's spectacularly difficult. I'm active on the data management mailing
                list, although not much longer because it simply isn't worth the effort,
                and the level of denial and general narrow-mindedness within the DM
                community is simply astounding. They literally have conversations such as
                "I haven't found work in 2 years now" followed by "this agile stuff is
                bunk" and yet are unable to put two and two together. How sad.



                >The only way to build cooperation I know of is to align interests. If
                >Agilists assume that one approach is right (let the circumstances decide)
                >and the database team has another (everything in the database), how can we
                >expect to build an understanding?

                People have to be willing to work at it. This is why, IMHO, the
                philosophies of the Agile Data method
                (www.agiledata.org/essays/vision.html) are critical -- they lay a realistic
                foundation for co-operation. Unfortunately people need to be willing to
                cooperate.



                >Is it also possible that it isn't a case of one side being right and the
                >other wrong, but that each is right based on their own responsibilities and
                >goals?

                Yes, which is why both sides need to take the time to listen to and
                understand the other. Until that happens we won't be able to work together
                effectively.

                - Scott

                ><snip>

                ====================================================
                Scott W. Ambler
                Senior Consultant, Ronin International, Inc.
                www.ronin-intl.com/company/scottAmbler.html

                www.agiledata.org
                www.agilemodeling.com
                www.ambysoft.com
                www.enterpriseunifiedprocess.info
                www.modelingstyle.info
                www.ronin-intl.com
              • Adrian Howard
                On Monday, July 7, 2003, at 05:16 am, Marc Hamann wrote: [snip] ... [snip] I think that s often the case. For example, I had some problems on a project where
                Message 7 of 17 , Jul 7, 2003
                • 0 Attachment
                  On Monday, July 7, 2003, at 05:16 am, Marc Hamann wrote:
                  [snip]
                  > Is it also possible that it isn't a case of one side being right and
                  > the
                  > other wrong, but that each is right based on their own
                  > responsibilities and
                  > goals?
                  [snip]

                  I think that's often the case.

                  For example, I had some problems on a project where the DBA was saying
                  you have to have data X in database Y - because it was the "correct"
                  thing to do. I was saying that it would be a far "simpler" solution to
                  use a flat file. Using a database was complete overkill as far as I
                  could see. The customer was happy with progress and didn't see why the
                  DBA was complaining. We could have just carried on and ignored the
                  whole database issue.

                  However, after some investigation (and beer purchasing by both sides),
                  it turned out there was a hidden requirement that X related information
                  needed to be in database Y because of some larger company
                  data-warehousing/mining issues. This requirement was not known by our
                  customer. Indeed it wasn't really an explicit requirement anywhere -
                  but was known by the DBA.

                  So, a few new stories and customer tests (written by the DBA) and
                  everybody's happy. The DBA was extra happy because some of the "hidden"
                  work she did became visible to management. More beer for all parties
                  involved.

                  In my experience problems with DB folk have usually turned out to be
                  one of:

                  - Misunderstanding: The folk idea of agile/XP makes them think it's a
                  bunch of hackers who are anti-database. Sitting down an explaining how
                  it really works fixes this. Get them involved with the team and the
                  problem goes away.

                  - Policy: There's a company wide policy about relating to the databases
                  that isn't known to the customer or development team. Sometimes only an
                  implicit one. Make that policy explicit in some stories and the problem
                  goes away (either you use the database, or the customer makes the
                  decision not to).

                  Assuming that the DB folk are not idiots and have a reason for their
                  behaviour usually turns out to be correct.

                  Of course, there are always occasional bull-headed people (on both
                  sides) who just won't listen to reason. They want to do it their way
                  regardless of whether there is any actual benefit.

                  When this happens I try and get the customer involved directly (after
                  all, it's their DB). I add stories for any extra work involves and show
                  how project velocity drops as soon as there are interactions with the
                  DB team.

                  If you have an onsite customer what's happening is usually obvious.

                  Cheers,

                  Adrian
                • Marc Hamann
                  ... Absolutely. One of my concerns about Agile is that some people are already talking about it as the right way . ;-) ... I must say that I was appalled at
                  Message 8 of 17 , Jul 7, 2003
                  • 0 Attachment
                    At 06:32 AM 7/7/03, you wrote:
                    >To be fair, many developers will start with the "one right way" themselves.

                    Absolutely. One of my concerns about Agile is that some people are already
                    talking about it as the "right way". ;-)

                    >It's spectacularly difficult. I'm active on the data management mailing
                    >list, although not much longer because it simply isn't worth the effort,
                    >and the level of denial and general narrow-mindedness within the DM
                    >community is simply astounding.

                    I must say that I was appalled at some of the posts that were directed at
                    you. Even if you don't agree with someone, it strikes me as bad mailing
                    list karma to foam at the mouth at them.

                    I discovered that I don't seem to be able to post to that list, but luckily
                    there were other friendly (or at least civilized) voices who could.


                    >They literally have conversations such as
                    >"I haven't found work in 2 years now" followed by "this agile stuff is
                    >bunk" and yet are unable to put two and two together. How sad.

                    To be fair, I don't know that one can connect the two directly. Where I
                    live (near you, I understand), putting Agile Alliance on your resume is
                    still more likely to LOSE you a job offer. ;-)

                    I get the distinct impression that many of them are trying to escape the
                    slump by dissociating what they do from IT in general.


                    >People have to be willing to work at it. This is why, IMHO, the
                    >philosophies of the Agile Data method
                    >(www.agiledata.org/essays/vision.html) are critical -- they lay a realistic
                    >foundation for co-operation. Unfortunately people need to be willing to
                    >cooperate.


                    Well, ultimately I agree with you. I'm very glad that you have undertaken
                    this work to find ways to bring Agile to data. (Thanks for you efforts, BTW)

                    I guess the practical issue is: can we find a way to show the utility of
                    Agile in terms of _their_ values, or is it practically a contradiction of
                    terms?
                    For example, I have frequently been known to say that government
                    institutions are almost incapable of being Agile, since for them
                    accountability is more important than effectiveness. Is there a similar
                    principle at work for data managers?

                    >Yes, which is why both sides need to take the time to listen to and
                    >understand the other. Until that happens we won't be able to work together
                    >effectively.

                    The first challenge may not be listening per se, but rather having a common
                    language to communicate in. Even understanding both sides, I'm not sure I
                    have a solution for that yet.

                    Marc
                  • Marc Hamann
                    ... Thanks for the anecdote Adrian! Among other things, I learned that beer is the universal language. ;-) Marc
                    Message 9 of 17 , Jul 7, 2003
                    • 0 Attachment
                      At 06:36 AM 7/7/03, Adrian wrote:
                      >However, after some investigation (and beer purchasing by both sides),
                      >it turned out there was a hidden requirement that X related information
                      >needed to be in database Y

                      Thanks for the anecdote Adrian!

                      Among other things, I learned that beer is the universal language. ;-)

                      Marc
                    • Scott W. Ambler
                      ... Exactly. The sad thing is that it really only is a couple of cranks on that list that are ruining it for everyone. The list admin needs to moderate it a
                      Message 10 of 17 , Jul 7, 2003
                      • 0 Attachment
                        At 09:26 AM 7/7/2003 -0400, Marc wrote:
                        >At 06:32 AM 7/7/03, you wrote:
                        > >To be fair, many developers will start with the "one right way" themselves.
                        >
                        >Absolutely. One of my concerns about Agile is that some people are already
                        >talking about it as the "right way". ;-)
                        >
                        > >It's spectacularly difficult. I'm active on the data management mailing
                        > >list, although not much longer because it simply isn't worth the effort,
                        > >and the level of denial and general narrow-mindedness within the DM
                        > >community is simply astounding.
                        >
                        >I must say that I was appalled at some of the posts that were directed at
                        >you. Even if you don't agree with someone, it strikes me as bad mailing
                        >list karma to foam at the mouth at them.

                        Exactly. The sad thing is that it really only is a couple of cranks on
                        that list that are ruining it for everyone. The list admin needs to
                        moderate it a little better.



                        >I discovered that I don't seem to be able to post to that list, but luckily
                        >there were other friendly (or at least civilized) voices who could.
                        >
                        >
                        > >They literally have conversations such as
                        > >"I haven't found work in 2 years now" followed by "this agile stuff is
                        > >bunk" and yet are unable to put two and two together. How sad.
                        >
                        >To be fair, I don't know that one can connect the two directly.

                        The real issue is that most of the people on that list are too narrowly
                        focused to change their ways. There are actually people on it that are
                        still in denial of object technology. Sigh.


                        > Where I
                        >live (near you, I understand), putting Agile Alliance on your resume is
                        >still more likely to LOSE you a job offer. ;-)

                        That's a shame. Don't worry, that will change.



                        >I get the distinct impression that many of them are trying to escape the
                        >slump by dissociating what they do from IT in general.

                        I highly suspect that they'll end up unemployed as a result. If you add
                        value then you'll stay employed. My experience is that many data
                        professionals have lost sight of this nasty reality, if they ever
                        understood it at all.




                        > >People have to be willing to work at it. This is why, IMHO, the
                        > >philosophies of the Agile Data method
                        > >(www.agiledata.org/essays/vision.html) are critical -- they lay a realistic
                        > >foundation for co-operation. Unfortunately people need to be willing to
                        > >cooperate.
                        >
                        >
                        >Well, ultimately I agree with you. I'm very glad that you have undertaken
                        >this work to find ways to bring Agile to data. (Thanks for you efforts, BTW)

                        Thanks. I only wish that more people in the data community felt that way.



                        >I guess the practical issue is: can we find a way to show the utility of
                        >Agile in terms of _their_ values, or is it practically a contradiction of
                        >terms?

                        I think it's a slow process. Whenever I work closely with data
                        professionals they eventually seem to understand, but for some reason they
                        don't seem to struggle without guidance/mentoring. I think it would be
                        interesting to do a Myers-Briggs test across the IT community. Gut feel
                        tells me that the data community has a different subset of personality
                        types, in general, than does the development community. It points to the
                        need to try different approaches.


                        >For example, I have frequently been known to say that government
                        >institutions are almost incapable of being Agile, since for them
                        >accountability is more important than effectiveness. Is there a similar
                        >principle at work for data managers?

                        I suspect so. Perhaps the data community and the government agencies
                        attract the same personality types?



                        > >Yes, which is why both sides need to take the time to listen to and
                        > >understand the other. Until that happens we won't be able to work together
                        > >effectively.
                        >
                        >The first challenge may not be listening per se, but rather having a common
                        >language to communicate in. Even understanding both sides, I'm not sure I
                        >have a solution for that yet.

                        This is actually one of the things that I'm trying to do with the Agile
                        Database Techniques book
                        (www.ambysoft.com/agileDatabaseTechniques.html). The first major section
                        explains the basics of both communities to set a common foundation from
                        which people can work.

                        - Scott



                        >Marc
                        >
                        >
                        >
                        >

                        ====================================================
                        Scott W. Ambler
                        Senior Consultant, Ronin International, Inc.
                        www.ronin-intl.com/company/scottAmbler.html

                        www.agiledata.org
                        www.agilemodeling.com
                        www.ambysoft.com
                        www.enterpriseunifiedprocess.info
                        www.modelingstyle.info
                        www.ronin-intl.com
                      • Marc Hamann
                        ... Actually, I got the impression that he was one of the cranks. ;-) (Though less vocal) ... I would bet that most people haven t heard of Agile or (even more
                        Message 11 of 17 , Jul 7, 2003
                        • 0 Attachment
                          At 09:56 AM 7/7/03, Scott wrote:
                          >Exactly. The sad thing is that it really only is a couple of cranks on
                          >that list that are ruining it for everyone. The list admin needs to
                          >moderate it a little better.

                          Actually, I got the impression that he was one of the cranks. ;-) (Though
                          less vocal)

                          > > Where I
                          > >live (near you, I understand), putting Agile Alliance on your resume is
                          > >still more likely to LOSE you a job offer. ;-)
                          >
                          >That's a shame. Don't worry, that will change.

                          I would bet that most people haven't heard of Agile or (even more likely)
                          have a "trade magazine" idea of what it is.

                          I don't think this has to be a problem, though. Personally, my goal is to
                          be effective, not to convert the world to the Agile philosophy. I would be
                          much happier if organizations didn't consider themselves Agile, but
                          implemented the practices, rather than that they stick "must have Agile" in
                          their job ads and practice BDUF or undisciplined approaches on a
                          day-to-day basis.

                          > Gut feel
                          >tells me that the data community has a different subset of personality
                          >types, in general, than does the development community. It points to the
                          >need to try different approaches.

                          My own take on it is that it is something like the P vs. J distinction in
                          Myers-Briggs. Some people are more focused on finding "correct" ways of
                          doing things. Others like to "go with the flow". Since the relational
                          data model has such longevity, especially compared to some other technology
                          "fads", it is a good place for people who like certainty more than the
                          thrill of the "bleeding edge".

                          Personally, I am fairly balanced between the two traits, so I tend to think
                          the best approach to problems requires a bit of both. ;-)

                          >I suspect so. Perhaps the data community and the government agencies
                          >attract the same personality types?

                          Government is all about propounding the "right way" to do things, isn't it? ;-)

                          >This is actually one of the things that I'm trying to do with the Agile
                          >Database Techniques book

                          I look forward to that hitting the shelves.


                          Marc
                        • Scott W. Ambler
                          ... I d be happy if people could get to the trade magazine level, assuming that the trade magazines got it right. ... Good observation. ... - Scott
                          Message 12 of 17 , Jul 7, 2003
                          • 0 Attachment
                            At 11:27 AM 7/7/2003 -0400, you wrote:
                            ><snip>
                            > > > Where I
                            > > >live (near you, I understand), putting Agile Alliance on your resume is
                            > > >still more likely to LOSE you a job offer. ;-)
                            > >
                            > >That's a shame. Don't worry, that will change.
                            >
                            >I would bet that most people haven't heard of Agile or (even more likely)
                            >have a "trade magazine" idea of what it is.

                            I'd be happy if people could get to the trade magazine level, assuming that
                            the trade magazines got it right.



                            >I don't think this has to be a problem, though. Personally, my goal is to
                            >be effective, not to convert the world to the Agile philosophy. I would be
                            >much happier if organizations didn't consider themselves Agile, but
                            >implemented the practices, rather than that they stick "must have Agile" in
                            >their job ads and practice BDUF or undisciplined approaches on a
                            >day-to-day basis.
                            >
                            > > Gut feel
                            > >tells me that the data community has a different subset of personality
                            > >types, in general, than does the development community. It points to the
                            > >need to try different approaches.
                            >
                            >My own take on it is that it is something like the P vs. J distinction in
                            >Myers-Briggs. Some people are more focused on finding "correct" ways of
                            >doing things. Others like to "go with the flow". Since the relational
                            >data model has such longevity, especially compared to some other technology
                            >"fads", it is a good place for people who like certainty more than the
                            >thrill of the "bleeding edge".


                            Good observation.
                            ><snip>

                            - Scott


                            ====================================================
                            Scott W. Ambler
                            Senior Consultant, Ronin International, Inc.
                            www.ronin-intl.com/company/scottAmbler.html

                            www.agiledata.org
                            www.agilemodeling.com
                            www.ambysoft.com
                            www.enterpriseunifiedprocess.info
                            www.modelingstyle.info
                            www.ronin-intl.com
                          • Richard Quinn
                            Actually, even The Economist has heard of it. http://www.economist.com/displaystory.cfm?story_id=S%26%28%280%25QQ3%2A% 0A In the latest of our series on
                            Message 13 of 17 , Jul 7, 2003
                            • 0 Attachment
                              Actually, even The Economist has heard of it.


                              http://www.economist.com/displaystory.cfm?story_id=S%26%28%280%25QQ3%2A%
                              0A

                              "In the latest of our series on managing innovation, we look at agile
                              programming. This is the culmination of many faddish ideas for producing
                              software more efficiently. But behind it lies a healthy emphasis on the
                              virtues of teamwork in a business plagued with prima donnas"

                              Luckily I have a subscription and was able to read that article.




                              -----Original Message-----
                              From:
                              sentto-7758546-286-1057594141-rquinn=web.de@... On
                              Behalf Of Scott W. Ambler
                              Sent: Monday, July 07, 2003 5:57 PM
                              To: agileDatabases@yahoogroups.com
                              Subject: Re: [agileDatabases] Data and Application: Two Solitudes?


                              At 11:27 AM 7/7/2003 -0400, you wrote:
                              ><snip>
                              > > > Where I
                              > > >live (near you, I understand), putting Agile Alliance on your
                              resume is
                              > > >still more likely to LOSE you a job offer. ;-)
                              > >
                              > >That's a shame. Don't worry, that will change.
                              >
                              >I would bet that most people haven't heard of Agile or (even more
                              likely)
                              >have a "trade magazine" idea of what it is.

                              I'd be happy if people could get to the trade magazine level, assuming
                              that
                              the trade magazines got it right.



                              >I don't think this has to be a problem, though. Personally, my goal is
                              to
                              >be effective, not to convert the world to the Agile philosophy. I
                              would be
                              >much happier if organizations didn't consider themselves Agile, but
                              >implemented the practices, rather than that they stick "must have
                              Agile" in
                              >their job ads and practice BDUF or undisciplined approaches on a
                              >day-to-day basis.
                              >
                              > > Gut feel
                              > >tells me that the data community has a different subset of
                              personality
                              > >types, in general, than does the development community. It points to
                              the
                              > >need to try different approaches.
                              >
                              >My own take on it is that it is something like the P vs. J distinction
                              in
                              >Myers-Briggs. Some people are more focused on finding "correct" ways
                              of
                              >doing things. Others like to "go with the flow". Since the relational
                              >data model has such longevity, especially compared to some other
                              technology
                              >"fads", it is a good place for people who like certainty more than the
                              >thrill of the "bleeding edge".


                              Good observation.
                              ><snip>

                              - Scott


                              ====================================================
                              Scott W. Ambler
                              Senior Consultant, Ronin International, Inc.
                              www.ronin-intl.com/company/scottAmbler.html

                              www.agiledata.org
                              www.agilemodeling.com
                              www.ambysoft.com
                              www.enterpriseunifiedprocess.info
                              www.modelingstyle.info
                              www.ronin-intl.com



                              Yahoo! Groups Sponsor
                              ADVERTISEMENT




                              To unsubscribe from this group, send an email to:
                              agileDatabases-unsubscribe@yahoogroups.com



                              Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                            • Marc Hamann
                              ... You can t fault the Economist for not having a clear opinion. ;-) Marc
                              Message 14 of 17 , Jul 7, 2003
                              • 0 Attachment
                                At 12:47 PM 7/7/03, Richard wrote:
                                >"In the latest of our series on managing innovation, we look at agile
                                >programming. This is the culmination of many faddish ideas for producing
                                >software more efficiently. But behind it lies a healthy emphasis on the
                                >virtues of teamwork in a business plagued with prima donnas"


                                You can't fault the Economist for not having a clear opinion. ;-)

                                Marc
                              • psadalage
                                I m a DBA and I love working with developers, the whole reason being I m more satisfied when I m working as a team to add business value to the client. I could
                                Message 15 of 17 , Jul 7, 2003
                                • 0 Attachment
                                  I'm a DBA and I love working with developers, the whole reason being
                                  I'm more satisfied when I'm working as a team to add business value to
                                  the client. I could fight and maybe get things done my way and waste a
                                  lot of time, or I could work with the developers and arrive at a
                                  better solution.

                                  I do think that there is right way of doing things and it does not
                                  have to be His/Theirs or Mine/Ours it could be the team that has a
                                  right way of doing things.

                                  One of the qualities of an Agile DBA is to become a member of the
                                  team, if your data folks are sitting in some far off building, move
                                  them to the location where the development is happening, this usually
                                  will give them a better idea of what people are trying to develop.

                                  Developers' pairing with DBA's and vice versa is also a great idea, to
                                  make understand the various issues involved in both the camps.

                                  I agree with Scott, that people need to be willing to work at it,
                                  learn new techniques, change their attitudes, and listen to others

                                  Over all, I think being a part of team trying to provide business
                                  value to the client will help everyone in question.

                                  Pramod


                                  --- In agileDatabases@yahoogroups.com, Marc Hamann <marc@h...> wrote:
                                  >
                                  > I don't know how many of you also follow the [dm-discuss] list (the dm
                                  > stands for data management), or followed the flame war that raged
                                  for past
                                  > couple of weeks (DM vs. agile), but I must say that it provoked a major
                                  > re-assessment for me of the "mission" of THIS list.
                                  >
                                  > As a preface, I should say that for most of my career in IT, I have
                                  > considered myself a "database developer" with significant
                                  responsibilities
                                  > for data management as well. In the last few years, I have tended to
                                  > consider myself a "data application developer" and am a committed
                                  > Agilist. So I have sympathies in both camps.
                                  >
                                  > The thesis of this list seems to be: if we (data managers and
                                  application
                                  > developers) could just stop fighting and blaming each other, we
                                  could use
                                  > each others skills to succeed in producing business value for our
                                  > customers/employers. To this end we must develop techniques to work
                                  > together and make both database and application "agile". Scott,
                                  Pramod and
                                  > others are blazing the way to developing these techniques.
                                  >
                                  > Now I whole-heartedly support this goal, and clearly this is working in
                                  > practice in some contexts, but my reflections upon the flame-fest
                                  have me
                                  > wondering if it isn't possible that, in the general case, it is overly
                                  > optimistic to expect a synthesis between the two.
                                  >
                                  > The reason is that, though both sides believe that they are producing
                                  > business value, the have radically different beliefs about how to
                                  provide it.
                                  >
                                  > The data managers (and my "data manager angel") believe that "data is
                                  > king", i.e. that the business value resides solely in the quality and
                                  > correctness of the data. From a data point of view, applications
                                  come and
                                  > go, but the data schema has to remain valid forever.
                                  > Thus the solution is to create the "correct" schema (well-normalized,
                                  > well-constrained, logic contained in the schema, etc.) and protect
                                  it from
                                  > the application with gate-keepers (stored procedures, triggers,
                                  etc.) In a
                                  > sense, to be a DM is to be instinctively committed to BDUF.
                                  >
                                  > The application developers (and my "application developer angel")
                                  believe
                                  > that business value is provided by giving people "smart tools" that are
                                  > easy to use and which simplify business processes. Good data is
                                  important,
                                  > but if people don't actually enter it, because the tool is too
                                  cumbersome,
                                  > or insufficiently useful to their daily activities, you won't actually
                                  > collect any. The risk of change is managed by being able to
                                  refactor (or
                                  > simply reprogram) the application as requirements change.
                                  >
                                  > Now, this isn't necessarily an insurmountable divide, but if you
                                  look at
                                  > what happens when you build your typical n-tier application, the
                                  problem
                                  > becomes clearer. For the sake of performance and application
                                  flexibility,
                                  > since database calls are expensive, you must duplicate in the middle
                                  > tier(s) a lot of the logic that the DM wants strictly in the DB.
                                  From the
                                  > DM point of view this isn't necessarily a problem; if the data is
                                  locked
                                  > down twice so much the better, so long as it is locked down
                                  definitively at
                                  > the DB. From the agile developers point of view, this is a major
                                  waste of
                                  > energy and increase in complexity.
                                  >
                                  > The response to this dilemma from each community seems to be to
                                  predict the
                                  > demise of the other. The DMs say "soon there won't be any application,
                                  > just meta-data". The developers say "soon the relational model will
                                  die
                                  > and we will just have persistence frameworks."
                                  >
                                  > I don't think either is endangered (or perhaps, given the IT slump,
                                  they
                                  > are both equally endangered ;-) ), and I don't see how, barring a major
                                  > technological advance, the _aims_ of the two groups can be
                                  systemically
                                  > reconciled, without asking one or the other to "come over" to the
                                  other side.
                                  >
                                  > A barrage of thoughtful replies to this dilemma might soothe this "dark
                                  > night of the Agile DB soul". ;-)
                                  >
                                  > Thanks!
                                  >
                                  > Marc
                                • Marc Hamann
                                  ... Just for the record, it appears that I had misidentified the Moderator, confusing him with another Patrick. My apologies for suggesting he was a crank.
                                  Message 16 of 17 , Jul 10, 2003
                                  • 0 Attachment
                                    At 11:27 AM 7/7/03, Marc wrote:
                                    >At 09:56 AM 7/7/03, Scott wrote:
                                    > >Exactly. The sad thing is that it really only is a couple of cranks on
                                    > >that list that are ruining it for everyone. The list admin needs to
                                    > >moderate it a little better.
                                    >
                                    >Actually, I got the impression that he was one of the cranks. ;-) (Though
                                    >less vocal)


                                    Just for the record, it appears that I had misidentified the Moderator,
                                    confusing him with another Patrick. My apologies for suggesting he was a
                                    crank. ;-)

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