Successful implementation starts with a well thought-out plan.
The information presented in this chapter provides guidelines on details to be considered while designing your streamed environment. The design of an environment is highly dependent on your business's particular data requirements. Every business is different. While businesses may share common architectures, the details of their data requirements can be as different, and as numerous, as snowflakes in a snow storm (or so says Confucius, or maybe would have, if he were alive today). The authors' goal is to point out what to look for in the details as this will be the "meat" of your design.
In a perfect world, every Database architect and System Engineer would have the luxury of the 80/10/10 methodology. 80% design, 10% implementation, and 10% maintenance (preferably proactive). Unfortunately, in the real world, the methodology ends up being more like 10/40/50, with maintenance being reactive rather than proactive. However, by taking into consideration the following design components of your system, you can get a better idea of how much implementation and maintenance you will have ahead of you.
In this chapter, we will cover a number of design considerations to be taken into account before implementing your Streamed environment, including (but not limited to):
- Data ownership and movement: Who, What, When, Where, Why, and How
- Resource availability and limitations
- Application and business rules
- Best practices
- The Streams Site Matrix Design Aid
In journalism, the recipe for a good article includes "who, what, when, where, why, and how." This same recipe can be applied to your distributed environment design.
First, look at why you want to replicate data.
Your reason could be any one, or a combination of, the above; as well as other reasons not mentioned. Understanding why you want to replicate will actually help you determine why you would use one tool or functionality over another. You will need to differentiate between the efficiencies of similar tools and functionalities available to you. The key word here is efficiencies. You may be able to effectively accomplish your goal using one or the other, but the reason why you would want to use one tool or functionality instead of another is determined by how efficiently the tool or functionality allows you to accomplish your goal.