Critical Success Factors in Agile Data Architecture
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.
