The Glacial MethodologyTM For Software Development

Scott W. Ambler + Associates
Home | Articles | Books | IT Surveys | Podcasts | Contact Us | Announcements | Site Map
Recently reviewed

The Glacial Methodology™ is a data-centric approach to software development based on sound software engineering concepts. As you can see in Figure 1, which depicts a typical timeline for a Glacial project, the Glacial lifecycle takes a traditional data-centric approach to software development which is serial in nature. The Glacial Methodology is composed of seven distinct phases:

  1. Project Initiation
  2. Conceptual Modeling
  3. Logical Data Modeling
  4. Physical Data Modeling
  5. Application Development
  6. System and Acceptance Testing
  7. Deployment

Figure 1. A typical Glacial timeline.

1. Project Initiation

During this phase you put together your project team and project plan. A Glacial team is typically comprised of a Project Manager, a Data Team lead (the person who is actually in charge), a Senior Data Architect, several Junior Data Architects, several Data Analysts, a Database Administrator (DBA), one or two application developers, and perhaps a tester or two. Your project plan will be driven by the lifecycle of Figure 1, with critical milestones being the delivery of the conceptual data model, the logical data model, and the physical data model.

You must also put important control processes in place, the most important one being a comprehensive requirements change management to prevent scope creep. 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.


2. Conceptual Modeling

Conceptual data models explore the main business concepts and their interrelationships. Your conceptual data model forms the foundation upon which all development is based and that it is therefore imperative that you start with a highly detailed, reviewed, and accepted model. It is possible to finalize a conceptual data model within the first six to eight weeks of your project.


3. Logical Data Modeling

The third Glacial step is detailed logical data modeling. A logical data model (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. Following this methodology you will potential put your LDM into 74th normal form, although practically you only need to go somewhere between 67th and 72nd normal form.

Ensure that you seek the one truth when you are modeling data. Regardless of how long that it takes to come to consensus, strive to enforce a single definition for all data elements and entities. Without such a consensus there is no possible way for your organization to work effectively.

You should still focus on developing an LDM even though the application development team 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.


4. Physical Data Modeling

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.


5. Application Development

After several months of comprehensive modeling development activities are permitted to begin. Now that the physical database schema is defined and baselined, it doesn't really matter what the application developers do from now on. In fact, they might even choose to completely ignore the wonderful work done by the data professionals with the naive excuse that working software needs to be delivered sometime this decade. Pay this no heed, even if the application developers do go rogue you'll be able to prevent them from deploying into production because the business stakeholders respect your opinion.

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. These minor issues will be addressed by the development team when it goes rogue.

So what should data professionals do when the application developers attempt to actually get something done? The Glacial MethodologyTM includes strategies to deal with this very issue, such as:

  1. Database change management procedures. With sufficiently onerous database change management procedures we can slow, if not prevent, schema changes by development teams.
  2. Centralized database control. By requiring development teams to work solely through the data group we can ensure that they have to work with us. Luckily, there is no possible way application developers could work around data professionals without their knowledge.
  3. Rigorous quality control. Comprehensive reviews of both data requirements and database designs can ensure quality after the fact.
  4. Walking the talk without walking it. We only need to claim responsibility for data quality within an organization, data professionals don’t need to waste any time developing regression test suites for our databases. Nobody has noticed them doing this so far, so this strategy should continue to work.
  5. Promote specialization of skills. Data professionals must prevent application developers from gaining data skills, ensuring whenever developers do “go rogue” that that they will do a poor job designing the database. Once they’re eventually caught data professionals will be able to point out that poor data quality is application developers fault, even though they claim to be responsible for data quality.

6. System and Acceptance Testing

Although there is likely no time left at the end of the project, the Glacial MethodologyTM promotes comprehensive testing at the end of the lifecycle. System testing, in particular load and integration testing, are particularly important at this point.

A key to your success is acceptance testing to make it look as if your business stakeholders actually still want whatever it is that has been built. Call it like it is, after spending millions of dollars on the system, the business stakeholders are going to accept the system like it or not. When you think about it, traditional acceptance testing such as this should be called "Ram it down their throat" testing.


7. Deployment

Assuming the project hasn't been cancelled by this point, you will deploy whatever was actually built into production.


8. Summary

Yes, the Glacial Methodology is an April Fool's joke. If this methodology sounds similar to how your organization works, you've likely got a serious problem. Here is a list of resources for alternative techniques which you may want to consider:



Suggested Reading

Disciplined Agile Delivery This book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise describes the Disciplined Agile Delivery (DAD) process decision framework. The DAD framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and provides the foundation for scaling agile. This book is particularly important for anyone who wants to understand how agile works from end-to-end within an enterprise setting. Data professionals will find it interesting because it shows how agile modeling and agile database techniques fit into the overall solution delivery process. Enterprise professionals will find it interesting beause it explicitly promotes the idea that disciplined agile teams should be enterprise aware and therefore work closely with enterprise teams. Existing agile developers will find it interesting because it shows how to extend Scrum-based and Kanban-based strategies to provide a coherent, end-to-end streamlined delivery process.

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer. A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.




Disciplined Agile Delivery: The Foundation for Scaling Agile Agile Modeling: Practices for Scaling Agile Agile Data: Practices for Scaling Agile EnterpriseUP: Agility at Scale AgileUP: Towards Disciplined Agile DeliveryAmbysoft Inc. Software Development Practices Advisor Scott Ambler + Associates Follow @scottwambler on Twitter!


Copyright 2006-2012 Scott W. Ambler

This site owned by Ambysoft Inc.