“An Architect is the drawer of dreams”…Grace McGarvie
IBM Cognos TM1 gives us the ability to quickly and effectively prototype a business solution demonstrating to users proposed functionalities and capabilities of a system design rather than relying on only discussions and theory.
In some cases, it may seem like a good idea for your prototype to become the first iteration of the delivered system. However, once the “ah ha” moment has passed, it is critical to understand the difference between “It can do this” and “It will do this”.
Prototype or Develop?
During prototyping, concepts are rapidly explored to determine “if” or “how” requirements can be meet; during development, architectural best practices should be followed to insure that what is built and delivered “will” meet or exceed requirements.
Practical Architectural Concepts
Here are some basic architectural best practice concepts that should be kept in mind when developing any solution.
Appropriate Abstraction
When solving any business problem, you should always look for “natural joints”. These will be your “break points” which will allow you to “modularize” the solution into “simple solution steps”.
For example:
- Identify (a “view of data” to be processed)
- Process (an identified view of data)
- Present (the results of processing an identified view of data)
Encapsulation and Information Hiding
Solution modules should not “know about the internals of another”. Using the above example, the solution module responsible for processing (a view of data) should not “care about” or “in any way be connected to” the modules that identify or present data.
Each module should specialize in solving its “own problem”!
Coupling
Solution modules should use a single, common “interface point” – that is, you should design modules to exchange information with other modules (or other applications) through one common “gateway” – removing any complexity of “translation of information” from the solution module – solve that problem once. For example, if it’s common occurrence for applications to interface with an enterprise data warehouse, than build a reusable interface module with that purpose in mind.
Scope & Life of Variables
Programming commonly requires the use of variables. It is important to have a strict policy governing the definition and use of all implemented variables. Some guidelines are:
- Know “when” and “when not” to initialize a variable
- Use naming conventions – to indicate the variable “scope” (public/private, global/local, etc.)
- Know its “role” – counter, comparator or accumulator?
Understand Murphy’s Law
Always practice “defensive programming” – especially in a distributed environment! Solution modules should never “assume”. Make sure each module in your solution can handle a “less than perfect” state. That is, that it performs an appropriate interrogation of all information it consumes, processes or presents and “knows what to do” with any exceptions.
Close
Remember, application requirements will almost always change and so will your application – but by using architectural best practices, you’ll be adjusting and not starting over.
