Dividing the usage of abstractions in three different levels helps to understand the required roadmap of starting to use them and the benefits gained once the abstractions start to cover entire solutions.

Level 1 – Using abstractions within single application

  • Controlling code-level implementation with logical architecture abstraction blocks
    • This step raises the focus above the implementation and platform level
    • Current .NET, Java, Objective-C, C++ on different platforms merge together under same architectural abstraction block
  • While it makes the design level control over the implementation absolute it also means that the design documentation is complete. Absolutely minimal, yet perfectly complete.
  • Removes all the unnecessary hand-written code in the areas that are covered with abstractions.
    • Code is written only on the specific spots that abstraction is not strictly covering
    • Everything around hand-written code can be refactored and fixed without touching the code
  • These smallest level abstractions are very simple to create, yet they still achieve absolute effectiveness in their respective covering area
    • ROI is practically immediate even within a single project-scope (if your project requires design-level documentation of any kind)
    • Trivializes the maintenance time and the “silent” information that binds the original coders to participate in the maintenance
  • If these abstractions are shared through common repository/branching they can be immediately reused with other alike architecture applications
    • 100% code reuse
    • Applications of same architecture look alike – regardless of the business rules or content. As long as they use the same reference abstractions as their base.
  • Microsoft Visual Studio already provides the tooling support to start using level 1 abstractions immediately – for anyone from single consultant to industry giant.

Level 1 boosts development against any platform or SDK with shared repository distributed reference abstractions. Implicitly documented abstractions completely replace current example code solutions and HOW-TO documentation.

When entire application is covered with abstractions (this simply means that the application is “designed”) we can focus on the benefits of Level 2.

Level 2 – Relying on the abstractions

  • Level 1 raises the focus entirely on the logical “design level “ abstractions.
  • Level 2 focuses on the fact that abstractions can rely on other abstractions, because they are fully version control controlled and at-changeset-level synced with each other.
  • Visualization of trivializing the mobile software development is one example of this
  • Full independent architecturally challenging features can be introduced as “feature block” abstractions
    • Adding features to existing base-abstractions
    • For today’s coding terms “generating compatible code on top of existing code with full control of the generation”

Level 3 – Controlling the entire solutions and their lifecycle

  • Lower levels have raised the logical design level n-levels above the platform/implementation
  • When the entire application structure is covered and controlled with abstractions, changing the abstractions will change the entire applications
    • Without touching any of the hand-written code, the applications can be upgraded simply by upgrading the abstractions that they are build on
  • New platforms can be added as targets for existing applications
  • Legacy platforms can be supported afterwards
    • Scheduling as a “second class platform” their support can be continued
    • Allowing open-source communities to maintain their abstractions


At this level the business case possibilities are practically endless compared to what software development was used to.

Abstractions can contain intelligence/logic that allows the mobile trivialization example, where end users do not have to know the exact data types, but rather just provide enough of “example data” where the abstractions make the guess of the proper data type.

Microsoft Windows dominance as developer preference is compromised because the abstractions are absolutely optimal way of making software and after making the reference abstractions the easiness of platform-specific usage vanishes. As abstractions can target multiple similar platforms simultaneously, there is no specific reason not to support Linux and Mac alongside with the Windows platform.

Entering the application and solution “integration-abstractions” will allow anyone to participate in complex multi-component solutions. The final solution can be hand-picked to contain the preferred single parts that still are guaranteed to integrate perfectly with each other.

The industry will shift to abstractions simple because they are dramatically more efficient to use and complete replace the HOW-TO portions. The more difficult the “example” application code the better gain from abstractions. Especially marginal areas of specific embedded programming or other low-volume development with inferior development tools will get huge boost as their effectiveness gets in line with the rest of the platforms.

Last edited Jan 26, 2011 at 9:29 PM by kallex, version 2

Comments

No comments yet.