Introduction to Application Development Frameworks

The complete "Chapter 1: Introduction to Application Development Frameworks" from the book, Building an Application Development Framework (Packt, 2025), by Ivan Padabed and Roman Voronin

Oct 23, 2025

In this book we will be delving into the different aspects of an Application Development Framework (ADF) lifecycle, allowing individual software engineers, development teams, and engineering organizations to benefit from ADF’s great potential. The initial chapter of the book is focused on providing a wide context for future chapters, setting a common ground for all ADF stakeholders, and introducing basic classifications and definitions for future use.

The concept of Application Development Framework (ADF) has been well-known for a long time, but we need to set up a crystal-clear context for further reading. This is important because it helps us deal with this complex topic by setting common ground for definitions and classifications that will be used throughout the book. First, we explore the evolution of the idea of ADF. After that, we discover the differences and connections between other SDLC-focused technologies, such as Platforms, Libraries, SDKs, and APIs, to craft a brief but concise definition that helps us keep a big picture while diving deep into implementation topics. Then, we review the place of ADF in the Software Development Lifecycle to identify and prove the advantages of adopting an ADF.

In this chapter we’re going to cover the following main topics:

Introduction and historical references
Breaking down Application Development Framework
Exploring ADF and Platforms, Libraries, SDKs, APIs
Integrating into Software Development Lifecycle (SDLC) and Flow
Differentiating ADF and other types of Frameworks

Introduction and historical references

Engineers have a long and productive history of creating building blocks for their own convenience. If we do not ignore this historical experience, we can learn many useful lessons for creating our own frameworks.

From the very beginning of the software industry, engineers and scientists have had a tendency to reuse their most successful and efficient ideas. There are quite a few historical practices that share the core objectives of a framework:

Architectural Blueprints: Since ancient times, complex structures like buildings or ships were built based on detailed plans. These plans defined the overall structure, components, and relationships - similar to how frameworks provide a blueprint for software architecture.
Modular Design in Engineering: Even before the computer age, engineers approached complex machines with a modular mindset. Think of early steam engines with interchangeable parts - a principle that carries over to software components within a framework.
Mathematical Frameworks: For centuries, mathematicians have relied on established frameworks like algebra or calculus to solve problems. These frameworks provide a set of rules and structures that guide the approach to solving a specific type of problem.

While these aren’t direct equivalents to software frameworks, they all represent historical approaches to structuring complex systems in a way that aligns with the core function of a software development framework—to simplify the lives of its users when dealing with complex problems.

With the advent and adoption of computers, the concept of a framework has gone beyond the art of the elite and has become part of the daily work of many programmers. The idea evolved as computers themselves developed. Here are some contenders for the title of earliest software framework:

Early Subroutine Libraries (1940s – 1950s): In the early days of computing, programmers might develop reusable code blocks for common tasks like mathematical functions or input/output routines. These weren’t full-fledged frameworks, but they offered a basic level of reusability and structure.
FORTRAN Compilers (1950s): FORTRAN introduced the concept of high-level languages, allowing programmers to write code that is more human-readable than machine code. While not exactly a framework, it provided a foundational structure for building software.
Operating Systems (1960s onwards): Operating systems like IBM’s OS/360 offered a platform for running applications. They provided core functionalities like memory management and device drivers, which later frameworks were built upon.

It’s important to remember that the concept of a software development framework as we know it today – offering a comprehensive set of tools, libraries, and design patterns – is a more recent development. However, these earlier practices laid the groundwork for the frameworks we use today. In the modern world, we can only imagine the practical purpose software created on top of one or multiple frameworks.

Note
This book uses both terms “software development framework (SDF)” and “application development framework (ADF)” interchangeably. Usually, “application” is not exactly the same as “software”: we have platforms, libraries, SDKs, engineering tools and frameworks as alternative kinds of software. But in the context of the topic (“building frameworks”) we can always safely assume that any “software” we are going to develop with our frameworks will serve the same purpose as “application” with a minor exception of “infrastructure management frameworks” which are mentioned explicitly.

While most of the information on the internet about Application Development Frameworks is focused on web and mobile development, we cannot ignore trending frameworks from a non-application software, such as

Artificial Intelligence and Machine Learning (like PyTorch, TensorFlow, and Apache MXNet),
Scheduled task management (like Celery, Temporal, and Apache Airflow),
Infrastructure management (like Terraform, Pulumi, and Crossplane),
Testing automation (like Selenium, Robot, and webdriverIO),

and many others, including “hybrid” frameworks that provide multiple capabilities at once.

Fortunately, foundational principles of building software frameworks are common between classic ADF and these emerging types of SDF.

There are also vertical ADFs, aiming to cover corresponding business domains. Examples of such frameworks include Gamedev (Flame, Monogame), Data Visualization (Shiny, Seaborn, TensorBoard), Hardware Instrumentation (LabVIEW), etc.

A StackOverflow research in 2023 that involved approximately 90,000 software engineers provided us with data about frameworks they use daily (See Figure 1.1 that summarizes one of the framework-related topics from this survey). In addition to those numbers, we know that many frameworks have their own communities outside of StackOverflow, which means that more than 100k engineers work with software frameworks on a daily basis.

Figure 1.4: StackOverflow research summary chart

Figure 1.1: StackOverflow research summary chart

With all the wide adoption of ADFs, it is confusing to see how many different inconsistent definitions and classifications we have all around the internet. In the following section, we will craft a brief and concise definition based on ADFs unique differentiators in a world of software engineering.

Breaking down Application Development Framework

I often see engineers mixing up libraries, frameworks, and Software Development Kits. They use these words like they mean the same thing. Even more confusion can come if we add APIs, platforms, and DSLs to the conversation. But to make our own framework, we need to understand all these things.

According to Dictionary.com, the formal definition of the term “framework” is “a basic structure, plan, or system, as of concepts, values, customs, or rules”.

The collective unconscious of humanity, also known as LLM, suggests the following definition for ADF: An application development framework is a software library offering a fundamental structure for building applications within a specific environment. It acts as a reusable foundation, supplying pre-defined functionalities and promoting code organization through established conventions. This approach streamlines development by reducing repetitive coding efforts.

Both definitions are formally correct (except for “library” part of the second one, which I will explain later in this section). But they focus on how the framework is designed but have a lack of explanation about how it works. I am going to fill this gap by adding my own:

Definition
A collection of pre-written code and tools that provide a structured approach to building applications. It simplifies development by enforcing architectural patterns: frameworks always dictate an execution flow, and stipulate specific way to structure your code, promoting maintainability, testability, low coupling, and reusability.

It is a common misunderstanding to confuse frameworks with other engineering concepts aiming towards reusability, like API, software library, SDK, and platform. And there is always a special “tooling” category, which covers a wide range of software from smaller console scripts to powerful configurable logs processing pipelines – they all live their own life as they only used by developers to support their routine tasks, so we keep them out of conversation. Let’s set clear boundaries to understand their differences to focus on the most important aspects of our topic.

Application Programming Interface

Starting from API (Application Programming Interface) as the lowest-level implementation of the development tooling. The traditional understanding of API included any exposed interface available to software developers to perform manipulation with an external subsystem. This external subsystem was treated as a “black box,” which means that the developer should not worry about its internal implementation, tech stack, and logic. Thus, API provides a complete set of methods to deal with it. Modern understanding of the API concept drifted towards over-the-network API, like HTTP/gRPC/websocket APIs. Events and message-based communication interfaces are also subsets of APIs – like webhooks.

The best practice of API definition is to use open standards like OpenAPI and AsyncAPI schema languages, or other less popular languages like RAML.org or APIBlueprint.org. However, it is acceptable to use proprietary or vendor-specific tools. API concept can also be visualized with a simple diagram notation (see Figure 1.2 below). Typical representatives of the API are as follows:

SaaS products’ interfaces, e.g. PandaDoc API, or OpenAI LLM API
Cloud management APIs; e.g. AWS Cloud Control API , or Azure REST API, or Google’s Service Management API
Webhooks, like Zapier
Internal/proprietary messaging-based events and commands schema registries that can be based on Confluent or Redpanda

Figure 1.5: Concept-level diagram of API

Figure 1.2: Concept-level diagram of API

The diagram helps to see that the API purpose is to provide access to exposed “black box” functions.

Library

The next one to review is a software library as a collection of pre-written code or routines that developers can use to perform specific tasks or functions within their software applications.

Sometimes developers see any software library as a framework, but the purpose of the library is completely different – it focuses on runtime/operation concerns by implementing a common part of the system, like hardware I/O operations, network protocol, authorization sequence, ranking algorithm, IoT standard, etc. It is also common to have a library to transform a low-level API into a more developer-friendly form by adding enumerables, constants, and conditional logic over a binary code and method signatures of plain API. A Library usually operates as a gray box, which means that software developers can see its internal implementation, but it is rarely necessary. In some cases, libraries can come in binary format, which makes them black boxes.

Terminology across the industry is not always consistent, we can find other synonyms for the term “software library”:

Package; usually means one or multiple software libraries that share the same license and they can be distributed as a single unit.
Module; usually means a built-in software library, distributed with the program.
Extension (aka add-on or plug-in); usually means a software library that follows specific program interface allowing external developers to modify original program behavior without changing any code in the original system.

Another important consideration is control flow. For a software library, it is common for developers to have full control over the library functions – so developers are responsible for invoking the library.

Writing software libraries is one of the most common tasks in the industry; many senior developers have experience of creating libs for internal company purposes, or contributing to open-source libs, or at least have them as a part of their pet projects.

Often, a software library evolves into an SDK or a framework after multiple iterations of improvements. And we definitely need to build libraries as part of the ADF development.

To understand the idea of software library better, we can use real examples:

Algorithm libraries like math, or 3D, or ML
Hardware abstraction libraries like HAL or device drivers
Standard-compliant implementations like OpenAuth
Programming helpers like Boost or Requests.py that provide developers with a pre-written code for HTTP requests lifecycle syntaxis helper.
Any proprietary pluggable reusable code

Figure 1.6: Concept-level diagram of API and Library

Figure 1.3: Concept-level diagram of API and Library

The diagram suggests that Library can serve as a pre-implemented tool to integrate an API to the application; but basically, it can provide any pre-implemented code for reuse.

Software Development Kit

Similar functions can be also performed by Software Development Kits (SDKs) but they usually include much more than just a software Libraries; there is a list of possible SDK internals:

Libraries.
Tracing and Debugging tools.
Documentation.
Integrated development environments (IDEs)
Tests.
Plug-ins.
Application programming interfaces (APIs)
Sample code.

SDKs span both design-time (organizational) and runtime/operations (product) concerns but still with focus on a runtime. SDKs are also platform– or vendor-specific, they are developed by API or Platform vendors to improve their products adoption – see Android SDK created by Google (Alphabet) and Windows ASDK developed by Microsoft.

Sometimes bigger SDKs can be designed to include frameworks (like Apple SDK), but we can also see the opposite case, where an SDK is designed as an element of the framework. The following are examples of cases where SDKs are subsystems of ADFs in the list below:

Operator SDK is part of the Operator Framework
SDKs as developer-friendly lib wrappers for a particular framework, (for example) Treblle provides multiple SDKs including one for the Django framework
SDKs have the same control flow as libraries have: the developer is responsible for invoking an SDK, while in the case of frameworks, we usually have the opposite control flow: the framework is responsible for invoking developer’s code. There is no exception if the framework is part of an SDK: the framework takes ownership over the control flow.

Figure 1.7: Concept diagram of API, Library, and SDK

Figure 1.4: Concept diagram of API, Library, and SDK

The diagram above depicts the SDK as a super-entity for a library.

Framework

Let’s elaborate on our definition here:

A framework is a collection of pre-written code and tools that provides a structured approach to building applications. It simplifies development by enforcing architectural patterns: frameworks always dictate an execution flow, and stipulate specific way to structure your code, promoting maintainability, testability, low coupling, and reusability.

Of course, frameworks provide more than that, there are some examples below:

Hide low-level complexity behind a higher-level abstraction;
Promote faster development by providing pre-built binary/packaged components and functionalities;

But those additional benefits cannot be attributed exclusively to frameworks – libraries or SDKs both have the same value propositions.

The following are the Key aspects of this definition based on usage scenarios and key attributes:

“Framework as abstraction” conceals repetitive code and low-level details by applying software libraries, acting as a higher-level interface. This allows developers to work with core functionalities without getting bogged down in implementation specifics. However, it usually gives an option of direct communication with levels under even if it is unnecessarily for overwhelming majority of scenarios; in brief, any framework has one or multiple libraries coming as a built-in option or pluggable 3rd-parties.
“Frameworks as tooling” prioritize simplifying the development process by providing pre-built components, streamlined workflows, and reduced boilerplate code. Their primary focus is on accelerating development, while runtime considerations (like operations, maintenance, portability, performance) are a secondary benefit.
“Framework as architectural constraint” establishes a blueprint for system architecture. It dictates core components, their interactions, and overall structure, influencing key design decisions for developers working within the framework’s constraints.

And finally, the relations between a frameworks and APIs, libraries and SDKs are usually follow the common pattern: ADF streamlines the software development flow for the organization, governs the control flow by invoking a custom code made by software developer, having libraries as a proxy to access external subsystem APIs, and allowing to plug in a third-party libraries or SDKs to handle specific integrations.

Figure 1.8: Concept diagram of ADF, SDK, Library, and API

Figure 1.5: Concept diagram of ADF, SDK, Library, and API

There is an extended classification of the Application Development Frameworks:

Web frameworks like Django, Node.js, Java Play, Ruby-on-Rails, etc
Enterprise frameworks like Java Spring, Oracle ADF
Low-code frameworks like Flutter, OpenBlocks, Appsmith
AI/ML frameworks like TensorFlow, Keras, Apache MXNet
Gamedev frameworks like Unity, UnrealEngine
Mobile frameworks like React Native, Xamarin, Apache Cordova
Microservice frameworks like GoMicro, Spring Boot, Molecular
Test automation frameworks like Selenium, Appium, WebdriverIO
Desktop OS frameworks like MFC, OS X framework, KDE framework
Utility frameworks like Python Celery, ActiveTask,
Custom frameworks – proprietary ones build for internal use, usually applying ADF format for a domain objects and rules
As Frameworks are our focus area, we add more detailed specification for three ADFs to better highlight their commonalities.

The first one to analyze is Django:

It employs numerous libraries in pluggable way

It focuses on design-time aspects: “encourages rapid development and clean, pragmatic design”
It is responsible for a control flow – developers don’t need to invoke Django code but to follow a Django project structure to get their code invoked in a right moment;
It enforces multiple architecture patterns (MVC / MVT as a model-view-template, ORM as object-relational mapping, extendable middleware-based request processing pipeline, class-based views, etc)
It is vendor- and platform-neutral so it can be used on any cloud platform or a virtual machine that can interpret Python programming language;
It is a “gray box” software that can be redistributed as a package but it also has its source code published in a public GitHub repository under the BSD-3 OSS license

The second one is Node.js, the most popular web full-stack framework based on the JavaScript programming language:

It has number of standard built-in libraries listed in official documentation and hundreds of pluggable external libraries like listed here
Org design-time focus is clearly emphasized as a key success factor of this framework; …
(As Ryan Dahl said): “So for kind of technical reasons, adding a server onto JavaScript worked really well and people who were programming front end websites were able to take those same skills and with just a small amount of additional knowledge were able to program pretty nice web servers that could do long polling or other kinds of real time interactions. And I think there’s just a large base of JavaScript users out there, naturally, it being the language of the web, and so there was a lot of people who were able to take their skills and add on Node to that and suddenly become full stack developers.”
It is responsible for the control flow
It enforces architecture patterns like event-driven, microservices, API-first etc.
It is vendor- and platform-neutral
It is a “gray box” open-source software

And the final one is React, a modern web front-end framework based on the JavaScript language:

Dozens of libraries like here
Design-time focus: most of public sources mention developer-oriented benefits as a key advantage of the framework; this list includes declarative syntaxis, reusable components, community support, detailed documentation, etc.
Control flow management based on a virtual DOM concept is the core of the framework
React’s intrinsic architecture patterns include event-driven (hooks), container-based decorators, data repository (provider), etc.
It is vendor- and platform-neutral
It is a “gray box” open-source software

As we can see, most ADFs follow the same model which we will explore in more detail in Chapter 3.

Platform

And the final concept to review here is a Platform. The main differentiator of a Platform, in comparison with all the others: APIs, libraries, SDKs and frameworks, is its hosted server-side execution runtime. But it is important to understand that the runtime concern is a “bonus value” here because the fundamental benefits of Platforms are still organizational design-time toolings. Platforms usually combine that hosted execution backend with APIs, libraries, and SDKs; and it is common for modern Platforms to provide developers with more advanced tooling like dev portals, resource management console and UI, cloud IDE, infrastructure-as-a-code definitions support and many other org productivity boosters. However, platforms rarely include application development frameworks and vice versa. We still can see frameworks being part of the platform (like AWS Well-Architected Framework is part of AWS platform value proposition, and Microsoft also has the same one), but these are not ADFs but architecture design frameworks (set of values, viewpoints, blueprints and patterns for cloud-native applications).

Typical taxonomy with examples of the Platforms is the following:

Cloud platforms like AWS, MS Azure or GCP
Messaging platforms like Confluent Kafka or Redpanda
Task execution platforms like Temporal.io
Robotic process automation (RPA) platforms like WorkFusion or UIPath
Game Platforms like Heroic Cloud
Dev platforms like Split.io, Firebase, Launchdarkly

Figure 1.9: Concept diagram of Platform, Framework, SDK, Library, and API

Figure 1.6: Concept diagram of Platform, Framework, SDK, Library, and API

Platforms are the most complete and mature kind of reusable engineering elements; however, their value comes with a high cost of ownership – this means that only large-scale companies can afford to build and operate an internal software development platform. Please do not confuse internal SDP with commercial PaaS (platform as a service) – we have many examples that successful PaaS can be created and operated with relatively small investment.

Domain Specific Language

Here it is, the bonus addition to the chapter. A Domain Specific Language (DSL) is a “language” with a higher level of abstraction optimized for a specific class of problems. A DSL uses the concepts and rules from the field or domain.

Note
Please note that DSL is not a programming language but rather a “formal domain description” language. In most cases, DSLs implementations are closer to executable configuration in JSON, YAML, XML or similar formats.

In terms of architecture abstractions, extensibility, and control flow, DSL is very similar to ADF – they both imply certain design patterns, employ libraries for extensibility and portability purposes, and invoke necessary code in the right time, defined by DSL creators.

The difference is the level of freedom for software product developers to code the DSL execution. We may consider DSL a “next level” framework suitable for cases when we want to achieve a high grade of standardization at a high level of abstraction.

Typical simplified taxonomy of the DSLs is the following:

Workflow/BPMN like Camunda, Oracle BPMS, Nikku
Rules like Drools
Infra like Terraform
Development like Gradle

Figure 1.10: Concept diagram with DSL, Platform, Framework, SDK, Library, and API

Figure 1.7: Concept diagram with DSL, Platform, Framework, SDK, Library, and API

The diagram demonstrates a DSL primary use case of extending a Framework with limited predefined capabilities.

In this section we focused on key differentiators of Frameworks in comparison with other kinds of “engineering building blocks”. Now we can concentrate on the most important aspects of Frameworks, including the ones we further discuss in the next chapters.

Differentiating ADF and other Types of Frameworks

There are even more sources of confusion: we have Frameworks that could be used in the process of developing software products, but these Frameworks are not ADFs!

In the realm of software development, framework is a broad term encompassing various tools that structure and streamline different aspects of the process. We’ve established that Application Development Frameworks (ADFs) directly assist with coding. Let’s delve deeper into two other crucial categories: Architecture Frameworks and Software Delivery Frameworks.

…

Architecture Frameworks

These frameworks provide a structured approach to designing the overall architecture of a software system. Think of them as organizational architecture design process blueprints or roadmaps that define the foundation upon which your application will be built.

Here’s a breakdown of Architecture Frameworks’ types:

Enterprise Architecture Frameworks (EAFs): Focuses on the high-level structure of an entire organization’s IT infrastructure, including software applications, data, and hardware. Examples: TOGAF, Zachman Framework.

Software Architecture Frameworks (SAFs): Specializes in designing the internal structure of a single software application. Examples: 4+1 View Model, C4 Model.

The following are some of the benefits of adopting such frameworks:

Consistency: Promotes a standardized approach to design, ensuring all components fit together seamlessly.
Communication: Provide a common language for stakeholders (architects, developers, etc.) to discuss system design.
Reduced Complexity: Break down complex systems into manageable components, simplifying design and development.

The following are some of the popular examples of the architecture frameworks:

TOGAF (The Open Group Architecture Framework): A widely used EAF known for its comprehensive approach to enterprise architecture.
Zachman Framework: Another EAF, offering a framework for classifying architectural information across different viewpoints (e.g., business, data, application).
4+1 View Model: A SAF focusing on five architectural viewpoints (system, application, deployment, container, and code) for designing software applications.

(Another example is DoDAF)

Architecture Frameworks can be very useful, but they are completely out of scope of this book.

Software Delivery Frameworks

These frameworks focus on streamlining the entire software development and delivery process, particularly for large-scale or complex projects. They don’t deal with the specifics of coding or designing the application itself, but rather how to efficiently manage the development lifecycle.

Here’s a closer look at Software Delivery Frameworks:

Core Principles: Emphasize iterative development, continuous integration and continuous delivery (CI/CD), and agile methodologies.

The following are some of the benefits:

Improved Efficiency: Streamlines workflows and processes to deliver software faster and with fewer errors.
Enhanced Communication: Fosters collaboration between development teams, product managers, and stakeholders.
Increased Adaptability: Enables teams to respond to changing requirements and market needs more effectively.

The following are some of the popular examples:

Scaled Agile Framework (SAFe): A popular framework for scaling agile methodologies to large enterprises.
Large Scale Scrum (LeSS): An adaptation of the Scrum framework designed for large teams working on complex projects.
Disciplined Agile Delivery (DAD): A framework that integrates various agile practices with other project management methodologies.

These categories provide a glimpse into the diverse landscape of frameworks beyond ADFs. Architecture Frameworks ensure a well-designed foundation for your software system, while Software Delivery Frameworks guide the overall development journey with efficiency and agility. By understanding and leveraging these frameworks, you can build robust and successful software applications.

But as we decided to focus on ADF, we need to pay special attention to a Software Development Lifecycle topic as it covers the key value of using application development frameworks.

Software Development Lifecycle (SDLC) and Flow

To better understand Application Development Frameworks, we need first to understand key scenarios of ADF adoption.

To set up a context, we need to differentiate the design-time and operations (runtime) aspects of the software product development. It is important to note that the Software Development Lifecycle (SDLC) can be used as a “blueprint” for software product development iteration. Visual diagram of SDLC can help us better understand this aspect:

Figure 1.11: Spiral SDLC model is one of the most advanced SDLC models for software development: image credits to https://www.tutorialspoint.com/sdlc/sdlc_spiral_model.htm

Figure 1.8: Spiral SDLC model is one of the most advanced SDLC models for software development: image credits to tutorialspoint

We should always assume a repeatable iterative nature of the software product development process not because “agile” is our current state-of-the-art delivery methodology; every lean or efficient delivery approach relies on feedback loops to enable continuous improvement.

While ADF can be defined from both design-time and operations (runtime) perspectives, its primary value is always in design-time and SDLC. We can impact routines as repeatable and reproducible tasks. That’s how it is different from software libraries or APIs that can be employed for a one-time task that might never be repeated again (e.g. library that provides integration to specialized hardware or vendor-locked API that can be used in multiple places in source code, but the use of a library is not about repeatable part of SDLC task).

In systems engineering terminology we can declare that SDLC is a “using system” (or a supersystem) for ADF, and ADF is a “subsystem” of SDLC. This implies not only the fact that ADF is literally part of SDLC, but also enables the following mental model:

ADF value, success criteria, and metrics are targeting SDLC improvements
ADF stakeholders’ roles are SDLC participants
Key ADF architecture viewpoints are defined in SDLC

In addition to SDLC concept, which is focused on engineering and instrumenting the development process, we can apply a “Flow” term to emphasize the systemic aspect of software product development in terms of value throughput and delivery management.

ADF and Flow
…ADF (is) s one of the most influencing ways to optimize a Flow throughput and eliminate bottlenecks related to product and process complexity.

Summary

An Application Development Framework is a software product “skeleton” that offers a fundamental structure for building applications within a specific environment. It acts as a reusable foundation, supplying pre-defined functionalities and promoting code organization through established conventions. This distinguishes it from other ways of reusing code in the form of an SDK, library, or API. It also makes ADF a unique opportunity to streamline development by reducing repetitive coding efforts, decreasing cognitive load, and promoting architecture best practices.

With this knowledge, we can explore the next chapters to find a way to calculate ADF return on investment, meet stakeholders’ expectations, and align the ADF roadmap with a common maturity model.