To define something is to spend time in an ideal world where anything is possible and you can imagine, re-arrange and visualise the definition into anything you want. It becomes the ‘Ideal Definition’ of your goal, a masterpiece waiting to take form.
The sharing of this ideal definition becomes limited by the declared method of expression.
Pictures work well but are limited by the readers’ ability to understand what they have visualised in their mind. The use of visual tools requires an assumption of minimum understanding placed upon the consumer of the picture or a built-up story to get them there, like a Dilbert comic.
Languages (text symbols) in all forms work well but also have an assumed minimum understanding placed upon the reading of that written word. A story with index, footnotes, glossary and references work well to fill in any gaps of understanding; allowing the reader to jump all over the document in their quest for that ‘Ah, ha; I get it!’ moment.
“a declared implementation is always the lesser,
imperfect representation of the defined ideal”
Programming languages are a stricter implementation of a language that limits the expression to a maximum number of combinations. This is a limited syntax that can be learned and does not grow beyond the maximum of combinations of the keywords involved in the syntax. Programming languages are primarily focused on the flow of change.
Databases are a stricter implementation of a language that provides a limit of maximum combinations of expression with a primary focus on storage. Programming languages are used to control the flow of symbols in and out of a database. With these two limited forms of expression of language we now have a partnership, a duo, a team that can provide useful functionality.
Welcome to Data Warehousing, a way to access a lot of stored information and a way to change it.
The implementation of the ideal definition can take many different forms, each providing their own features complete with advantages and compromises. The expression of a definition into form is when it becomes ‘Declared’.
It can be said that all things have two or more perspectives, the defined ideal and the declared implementation(s). The variety of different available solutions comes from the gap between ‘the defined versus the declared’. This variance is incorporated into a lot of basic concepts:
- Ideal versus Real;
- Theory versus Practice;
- Definition versus Declaration;
- Compile Time versus Run Time;
- Object versus Instance.
This basic difference has significant implications on the usable features of a form; both within itself and its interaction with others. A good example of this is the native data type called ‘String’:
- The ideal approach is to say a defined string has no ‘Length’ property and a declared string has a length property with a valid value;
- A practical approach is to say a string always has a length property. The defined length is a value that is never used but when declared its length is a valid value;
- A convenient approach is to say a string always has a length property and is based upon a valid value. The defined length value is the same as the declared length value of the initial value.
The main difference between them is based upon the experience when used. Each has a significant impact on the features and complexity of the run time environment. Considering:
- No property versus property with NULL value;
- Property always has a valid value that is also a special case value (the initial value);
- Property always has a valid value with no concept of the separation between valid values and an initial value.
The above example highlights the diversity between a defined ideal of a ‘String’ and its multiple declared implementations that can offer different features, advantages and compromises. The choice of which declared implementation to use comes back to which technical debt are you willing to live with?
In the world of SAP Netweaver Business Warehouse (SAP BW) a lot of these initial choices have been made for you to leverage, as delivered/installed. The declared implementations have been wrapped up into a framework ready for use:
- A data dictionary to manage a limited list of grouped features;
- A data warehouse to organise the declared implementations;
- ABAP and Java programming languages to access and change the data;
- Configurable automation to leverage repeat processing.
The art of being an SAP BW Professional is to understand these pre-built definitions and declarations:
- How they function internally and interact externally;
- Their advantages and compromises;
- Practical arrangement and combinations to achieve desired solutions;
- Identify the location of the technical debt in the solutions;
- Choose the balance between speed, security and maintainability;
- What tools are available to interact with the features?
Question: What other examples can I think of where the difference between definition and declaration is evident within BW?
Perhaps Modified (M) versus Active (A) objects for data storage or Transported (T) objects used by the Transport Management System (TMS).