Scott Ambler on The Glacial Methodology™ Workshop: A Data-Centric Software Development Process

I love a tongue in cheek satire especially about dogmatically held beliefs.  Here is a great one by Scott Ambler.  It could readily be applied to those who believe in creating copious amounts of documentation and following a waterfall process instead of Keeping Agile.  Enjoy! –Brian

The Glacial Methodology™ is a data-centric approach to software development based on sound software engineering concepts. With a Glacial approach you begin by developing a conceptual data model, followed by a detailed logical data model (LDM), and then finally a detailed physical data model (PDM). After several months of this comprehensive modeling effort development activities are then permitted to begin.

Conceptual data models explore the main business concepts and their interrelationships. Workshop participants will learn that conceptual data models form the foundation upon which all development is based and that it is therefore imperative that you start with a reviewed and accepted model. Strategies for streamlining this effort will be presented, it is possible to finalize a conceptual data model within the first six to eight weeks of your project.

The next Glacial step is detailed logical data modeling. An LDM fleshes out business entities with detailed descriptions of their data attributes and the relationships between entities. Data requirements are gathered during this stage, information which is captured within your LDM as well as in your data requirements specification–Glacial data professionals understand the importance of comprehensive documentation. Strategies for putting the LDM into 74th normal form will be discussed, as will the need for practicality by only going to somewhere between 67th and 72nd normal form. During the workshop participants will learn how to justify a parallel LDM activity even though the application development covers the exact same ground, faster and more thoroughly, with their object modeling activities. A side benefit of the Glacial Methodology™ is that it ensures a large and growing data group within your IT department regardless of the obvious redundancy which they represent.

With a Glacial approach you develop a detailed physical data model (PDM) based on your reviewed and accepted LDM. The PDM is used to generate your database schema and to help drive the modeling efforts of the application developers (they still need to worry about a few secondary issues listed below). You need to invest significant time modeling it because it needs to be right, due to the fact that it is incredibly difficult to make changes to your database schema once it is in use.

A comprehensive requirements change management to prevent scope creep is a vital component of any Glacial process. All change requests must go through a change control board (CCB). In the case of requests affecting the database, the CCB must defer to the data group to ensure data quality. Instead of considering changed requirements immediately, it is far better to invest the time to consider each potential change thoroughly. Better yet, by following such an approach your stakeholders will soon learn to stop suggesting all but the most important changes–with the Glacial Methodology™, bureaucracy becomes your ally because it helps to minimize, if not completely avoid, change.

Following the traditions of the traditional data community, the Glacial Methodology ignores trivial issues which are better left to application development teams. These issues include, but are not limited to understanding the usage requirements for the system, system usability, security, network architecture, hardware architecture, deployment, scheduling, estimation, component design, user interface design, overall functionality, and testing. Justification for why all of these issues are secondary to data-oriented concerns, and political techniques for sidelining anyone naive enough to think otherwise, will be covered in detail.

About Brian Lucas

In his life, Brian Lucas has been a coach, farm worker, forester, health care advocate, life guard, general contractor, mechanic, mixologist, musician/singer (in a rock group), salesman and teacher. Brian has worked as a project manager, technical marketer, methodologist, manager, software architect, systems designer, data modeler, business analyst, systems programmer, software developer and creative writer. These efforts include over a hundred hi-tech initiatives in almost every business and industrial sector as well as government and military projects. Among them, he designed and developed a quality assurance system for the first transatlantic fiber optic communications network, a manufacturing system for a large computer manufacture’s seven manufacturing centers, a data mining system for steel production, an instrumentation system for cable systems, defined requirements for government’s information systems and designed and developed human performance management systems. Brian has educated and mentored many over the years, designing programs to discover and develop talent. He has also lectured extensively to a variety of audiences. Brian is currently devoting as much time as possible to the innovation of business agility and human capital management along with the next generation of agile software development. As an amateur theoretical physicist he is working on joining general relativity and quantum mechanics through a multidimensional time corollary on string theory and negating the uncertainty principle with Louis de Broglie’s wave/particle hypothesis. He is also an avid blue-water sailor and wilderness backpacker. He enjoys billiards, boxing, chess, cooking, famous battle reenactments and war gaming, fencing, flying, gardening, horseback riding, martial arts (particularly Ninjutsu), philosophy and psychology, playing musical instruments (7 so far), poker, rapid-fire target shooting, reading (he tries to read a new book every night), painting with oils, scuba diving, skiing and recently writing novels.
This entry was posted in Agile for Software Development and tagged , , , , , , . Bookmark the permalink.

13 Responses to Scott Ambler on The Glacial Methodology™ Workshop: A Data-Centric Software Development Process

  1. Dave says:

    I chuckled. But I really laughed while reading the last paragraph.

  2. Albetina says:

    this information is definitely going to help me with creative ideas, thanks a lot my friend. success.

  3. Jemes hand says:

    what you’ve said makes sense, and i can understand it very clearly, thanks.

  4. Doug says:

    i was surprised to see you post another persons work – you seem to focus on creating original articles and are good at it – this was funny though – could you cover more agile in the enterprise subjects from the point of view of an implementer…

    • Brian says:

      Doug while I don’t generally post others work here it is not from an egotistical “not invented here syndrome”. I think that bloggers that just regurgitate what they have read elsewhere show immense contempt for their readership. That is something I find repugnant.

  5. Dan says:

    Very funny! How many organizations exists that use the glacial methodology, I wonder?

  6. Fitzwalter says:

    I printed this out and put it on the desk of our tyrannical enterprise architect’s desk. Ha, Ha! Thanks for this!

  7. Garnet says:

    Funny man! I can’t believe some people are still stuck in the dark ages with stuff like this! Keep on blogging dude! Keeping Agile rocks!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s