The basic steps of abstraction start with separation — specifically, the designer’s separation from technology.
Given the business and functional requirements, designers tend to translate items as parts of a software product. This is natural. It in fact explains why translation is the fastest approach in software design. However, this is prone to the following pit falls:
- When operational issues come in, the software may lack manageability and maintainability;
- When technical support and enhancements come in, the software may lack extensibility and flexibility;
- When the enterprise starts to grow and change, the software may be difficult, if not impossible, to keep up to date.
In order to avoid these problems, the designer must first distance him/herself and start evaluating the current and future needs of the business. In most cases, the enterprise has year long plans of its future IT direction. Even for a software product, the company may know beforehand if it is a long term or a short term investment. The decision of the designer to build a software product in-house, or to purchase an existing platform product in the market, is driven by the knowledge of what ventures the organization intend to value most in the long run.
For example, if the enterprise needs an integration/interface solution, but might need it only for a specific application, not necessarily as something that will strongly drive the business, purchasing webMethods or Microsoft Biztalk Server might be an overkill. However, when the business eventually has plans of relying on it, like as a messaging hub, that will serve many important aspects of the company’s business operations, financials and reporting, both internally and externally, a little extra budget for the established products and technologies in the market may be considered.
So where does software design by abstraction come in? The actual abstraction comes in when the designer knows for a fact that he/she can think small or think big. The target size of the product should help evaluate how much simplicity or complexity may be introduced. It helps the designer decide how compact or how distributed the resulting product would be. It, likewise, helps the designer decide how to justify and fit everything within budget and within the capacity of the enterprise (development, operations and support; success, growth and expansion).
The separation from technology does not stop there. The designer continues to separate him/herself further from technology as he/she splits, slices and separates the requirements from each other. Each piece and bit of the requirements are variables which may be the:
- rules; and
All of these may be easily translated or mapped in to their corresponding software parts at a later time. How they are classified, categorized and organized matters when storage and activation decisions are to be made. Some of these variables are configurations, some data/information, some deliverables and still some are actually rules, logic and plain old common sense. Some are stored in files, some in a data store and, still, some in the programs themselves.
The designer may then continue to separate the variables from each other preferably without breaking their links and relationships. If in case those links and relationships are broken along the way, the designer must be able to conceptualize the ways and the means by which they may all be linked and related back together. These conceptualizations, in general, are made easy, nowadays, with the help of known models, patterns and best practices.
Abstraction is a process of separation resulting to an "explosion" of the requirements in to their equivalent technical artifacts. The best results are achieved when the designer is not focused on technology, but rather, when the designer is focused on the enterprise: its business and its future.