There are several fundamental concepts that prove to be critical success factors for
agile data architecture. These
concepts are:
- Data is only one architectural viewpoint. As I point out in
Agile Data Architecture
in Context, data is only one of several potential viewpoints to address. When you focus on a single
viewpoint, such as data, you run the risk of local optimization in that you'll make very good
data-oriented decisions, some of which will negatively impact other aspects of your architecture. To be
effective you want to expand your horizons and consider more than just data issues.
- Collaborate closely with your stakeholders. The Agile Modeling (AM) method
promotes the practice
Active
Stakeholder Participation
where you collaboratively work with your stakeholders, to the point where they are actively modeling.
Figure 1 overviews the relative amount of stakeholder participation on
agile initiatives. Note how enterprise modeling requires a split between senior leadership
participation, to provide vision and to make decisions, and domain experts (subject matter experts) to
provide details. Implementation, on the other hand, doesn't require as much stakeholder participation
and when it does it will be by domain experts to help provide details and to validate work.
Figure 1. Stakeholder involvement in modeling.
- Embrace evolution. Technologies change. Your stakeholders will change their minds about what they
want. Laws will change. Your competition will change. The business environment in which you operate will
change. Things will change. Embrace that idea and be prepared to evolve your assets and your way of
working (WoW) accordingly
- Artifacts should be just barely good enough (JBGE). The article How Much Modeling Should You Do?
explores the how to determine whether you've done enough modeling. Because the decision factors are
qualitative in nature, the amount of modeling that you require for a given situation will be determined
by an experience-based, "gut feel" decision.
Figure 2 explores the implications of this, overviewing five potential
strategies for determining when you've modeled sufficiently.
Figure 2. How much effort should we invest in an artifact?
- Think about the future, but wait to act. A key responsibility of an architect is to think about
the future. What will your stakeholders need? What will help to make them competitive? Where is
technology heading? Where is the business environment heading? As an architect you need to think this
way so as to guide stakeholders through making decisions that will enable them to easily adapt to
whatever changes occur when they do so. BUT, just because you're thinking it through now doesn't mean
you need to act now. A fundamental lean concept is to defer making decisions until the last responsible
moment. Traditionally data architects believed that because it is hard to evolve data sources once they
are in production that they needed to over model and over build their solutions. Agile data
implementation techniques, particularly those of the
agile database techniques stack
enable you to safely and quickly evolve your data assets, even databases being accessed by thousands of
other systems (or more). In short, you can wait to act.
- Data architecture assets should be consumable. Something is consumable when it meets the needs of
its customers, it is usable (easy to work with), and it is desirable (people want to work with it).
Agile data architects will work closely with their stakeholders, typically in an evolutionary manner, to
ensure that they are producing something that is consumable.
- Follow a fit-for-purpose WoW. Every person, every team, every organization is unique and facing
an evolving environment. The implication is that you need to choose a way of working (WoW) that reflects
the context that you face, and as that context evolves so must your WoW. This is why both the Agile Data
(AD) and Agile Modeling (AM) methods are described as collections of practices supported by an agile way
of thinking. The idea is that you will choose the right technique at the right time and apply it to the
extent appropriate. One strategy, one collection of "best practices" doesn't fit all situations.
- Agile data architects are generalizing specialists. A generalizing specialist
is someone who has one or more specialized skills (such as data architecture), as at least a general
knowledge of the technical domain in which they work (in this case information technology), has at least
a general knowledge of the business domain in which they work, and actively seeks to gain new skills in
both their existing specialties as well as in other areas. Generalizing specialists are often referred
to as craftspeople, "T-skilled" people, multi-disciplinary people, or cross-functional people. As Figure 3 indicates, people who are generalizing specialists are in the "sweet
spot" between the two extremes of being either just a specialist or just a generalist, enjoying the
benefits of both but not suffering from their drawbacks. Generalizing specialists are generally able to
collaborate with others more effectively, are more to choose the right thing to do in a given situation,
are less likely to write extraneous documentation, and are able to make higher-quality decisions because
they have a better understanding of how everything fits together.
Figure 3. Generalizing specialists are between the extremes being specialists or generalists.
Related Resources
