Abstraction, an an approach in the software design process, requires experience and business knowledge.
The experience is not necessarily in the context of experience in designing software. In fact, the experience is usually a hands-on exposure to an existing product which triggers and inspires ideas. For example, an existing dialog form in Windows may inspire the list of parameters in defining the connection strings to the database. Or perhaps, you may find data mapping strategies and techniques from the data mapping tools of Microsoft Biztalk Server, Microsoft SQL Server’s SSIS, HiT Software’s Allora and Stylus Studio.
The business knowledge drives the depth of abstracting the requirements. To abstract or to translate? When do you keep abstracting? When do you stop? How do you intend to implement it? How do you plan to support it? Abstraction may be a powerful approach but it shouldn’t be an overkill. Abstractions tends to make the software very advanced and complex. The risk of complexity should be contained within the software so that how it works inside are transparent to the users. At the end of the day, what matters to users is that the product just works.
Abstraction may lead to invention, innovation and customizations of technologies. It may lead to building frameworks and architectures that could re-define the future direction of the IT organization. Most of the software products available in the market are designed through a lot of abstraction. Consider the Castle Project’s Windsor, the Microsoft Enterprise Library, AJAX-based products, Netbeans, SAP, etc. Consider also the amount of abstraction needed to achieve specific product features like the new Microsoft Office 2007’s ribbon, Apple Mac OS X’s Spotlight search, Microsoft Money’s user interface, Oracle OWB tools, etc.
When you start building your software with the future in mind, consider abstraction as an approach. It might slow you down at first. But in the end, it empowers and enables the IT organization for the enterprise.