Implementación de la solución inicial

1. What is our design objective—to improve our own understanding or to communicate the solution to others?

2. Have we accomplished our objective yet (i.e., have we done enough for now)?

3. If so, what’s keeping us from getting started developing?

4. If not, what is the smallest/simplest thing we can do to accomplish our objective?

Continuously asking this sequence of questions will help the Agile Analytics team avoid the temptation to spend too much time doing up-front design while helping ensure that they don’t start developing without the important prerequisite design decisions.

Agile Analytics Practice: Architecture Envisioning

During iteration zero seek to develop a minimally sufficient up-front design. Look for opportunities to do less up-front design without falling below the “minimally sufficient” threshold. This will leave the develop- ment team with more empty canvas to work with as you adapt and evolve the design.

A

M

An Agile approach to modeling is essential to evolving excellent designs. An Agile model is one that is minimally sufficient. This means that it conveys just enough to be useful while remaining malleable and adaptable. Agile Modeling is an iterative, incremental, and evolutionary approach that calls for a repeating cycle of modeling in small increments, proving your model with working code, and inspecting and testing the results. An Agile model has the following traits (Ambler 2002):

 It fulfills its purpose. We model for one of two reasons: to commu- nicate a design to others, or to better understand what we’re working on. Agile Modeling is done with clarity of purpose. When modeling to communicate, know who the audience is and what is being com- municated. When modeling to understand, know what the question is, who should be involved, and when the goal is reached.

 It is understandable. Agile models are developed with the intended audience in mind, using the correct “language” for that audience. If we are modeling to understand the business domain, use-case

ptg6843605

diagrams and business lingo are appropriate. For data modeling, a modeling notation such as an entity-relationship (ER) or UML 2.x class diagram is more appropriate.

 It is sufficiently accurate. Agile models don’t need to be 100 per- cent accurate, but they do need to be accurate enough to serve their purpose. For example, if I am drawing a map to show you how to get to my house for a party this weekend, a simple sketch with street names and directions will suffice. It doesn’t matter if it isn’t pre- cisely to scale.

 It is sufficiently consistent. Agile models don’t need to be 100 per- cent consistent, but they do need to be consistent enough to serve their purpose. For example, a logical data model with a “Customer” table may be inconsistent with a use-case model that refers to a “Cli- ent” actor, yet this doesn’t result in major misunderstandings of the two models.

 It is sufficiently detailed. The degree of detail in an Agile model depends on its purpose and audience. Drivers need maps that show streets and intersections; building contractors need maps that show civil engineering detail.

 It provides positive value. The more formal the model, the more costly it is to maintain. A digital picture of a conceptual model on the whiteboard is inexpensive compared to a formalized model drawn in a data modeling tool like ERwin, Rational Rose Data Modeler, IBM (InfoSphere) Data Architect, or some other profes- sional modeling tool. An Agile model’s value outweighs its cost of creation and ongoing maintenance. If a model is worth formalizing, it is worth keeping updated. Formalized models that are out-of-date have negative value.

 It is as simple as possible. In Agile models the level of detail is lim- ited to only what is needed to serve their purpose. Furthermore, the notational symbols are limited to only what is necessary.

Note the recurring theme of purpose in these Agile model trait descrip- tions. Too often DW/BI practitioners fall into the trap of creating and for- malizing models without a clear sense of purpose. When that happens, the models and corresponding documentation often become bloated and over- developed, and correspondingly more costly to create and maintain. The most accurate documentation of a DW/BI system is the system itself. Sup- porting documents are always at risk of being out of sync with the actual implementation. The best design documentation is a self-documenting implementation.

ptg6843605 AGILE MODELING 151

Agile Modeling is driven by these guiding principles:

 The working solution is your primary goal. Model just enough to get back to the business of building a working DW/BI system.  Enabling the next effort is your secondary goal. A DW/BI system

must be built with an eye toward the future, but it doesn’t need to be built to handle all future possibilities. Part of fulfilling the needs of stakeholders is designing a system that is robust and extensible over time.

 Travel light. Create just enough models and documentation to get by.  Assume simplicity. The simplest solution is usually the best solu-

tion. Don’t overcomplicate the design.

 Embrace change. Change is inevitable. Anticipate it and design for it. Don’t expect to get the design exactly right once and for all time.  Make incremental changes. Work in small steps and avoid big

sweeping changes.

 Model with a purpose. If you can’t identify why you are modeling and for whom, don’t do it.

 Create multiple models. There are a variety of modeling techniques and notations. Be sure to use the right tools for the intended pur- pose, and develop multiple models in parallel if it helps.

 Ensure quality workmanship. If the model is worth formalizing, it’s worth formalizing with high quality. Like high-quality code, high- quality models are elegant and rich with useful information. They are not sloppy and incomplete.

 Obtain rapid feedback. Share your models with others early and fre- quently to avoid heading too far off course. Publicize stable models and invite input.

 Maximize stakeholder investment. Involve stakeholders in the modeling process whenever possible. This will help avoid model- ing in a vacuum and will shape the models to more effectively meet stakeholder needs.

Agile Modeling is an attitude and style, not a prescriptive process. It is not a replacement methodology. Instead, it supplements and complements exist- ing modeling methods. Agile Modeling is a way for developers to collabo- rate and evolve excellent designs that meet the needs of project stakeholders. There is nothing magic about Agile Modeling, but it is a cornerstone of evo- lutionary design. Scott Ambler’s book entitled Agile Modeling offers a more comprehensive coverage of the values, principles, and practices that make up this approach (Ambler 2002).

ptg6843605 Agile Analytics Practice: Prove It with Code

Avoid the temptation to model in large steps with lots of design revisions. Instead, model in small increments and prove out your ideas by imple- menting them. And don’t forget to test as you go.