Motivations for & Goals of tao.js
So why do we need tao.js? Don't we have libraries and frameworks that do this already?
There are several motivations behind creating tao.js that originate from a need to describe software effectively for technical members (developers, QA, etc.) and non-technical members (product managers, designers, etc.) of teams alike.
This original need led to the creation of the TAO and implemented in tao.js as a way to build applications and systems which then presented an opportunity to achieve the original inspired intent of communicating a description of software through a simple grammar.
Brief Origin Story
Very briefly, what initially started by using a 3-Dimensional Matrix to describe the needs of an Application Platform turned into a way to model an Application. When combined with some other architectural models, this new model or way, aka the TAO, then materialized into a core architecture for writing Applications.
Short Systems Engineering Theory of the TAO
With the realization that the TAO could be used to actually build the software it was being used to describe, it became apparent there was a lot of value in a system that could be used to build software which had its design roots stemming from defining the software in the abstract or non-technical way.
Breaking down the concept of Software Architecture to its basist core, it can be defined as:
the set of answers to the questions posed by a Software Engineer when it comes time to implement a feature of an Application or System
Using the TAO as an architecture thus means it's providing these answers when it comes time to build an Application and add features to it.
Hence the birth of tao.js. However, to be truly ubiquitous and provide the most value, we would eventually like to port the TAO to other languages and frameworks, and will graciously accept help in that regard.
The origin and theory behind the TAO led to a set of 4 distinct motivations, each with their own set of goals:
- Build Apps in a Way that allows them to Evolve effectively
- Make it Easy to build Apps with good Architectural Foundations
- Codify Software Product Descriptions
- Empower Developers with Flexibility of Technology Choices
We'll step through each motivation here.
1. Build Apps in a Way that allows them to Evolve effectively
It's the desire of all code to become legacy
- Wise Old Developer
As developers and product managers, we want to build Applications that have a chance to evolve over time.
Primary to the TAO is a desire to build Applications in a highly Iterative fashion so that a core value is easy to create, and the App can evolve effectively in any direction as necessary without the unnecessary introduction of technical debt.
This comes with 2 Primary Goals:
- Applications are always composable and decoupled
- Build Apps like Building on a Platform
- Use a mechanism built-in for Extension Points that can expand over time
- Any App built with the TAO can be injected with New Features during execution
- Features unknown at the beginning of the life of an App are added the same as the First Feature
2. Make it Easy to build Apps with good Architectural Foundations
After many decades of building software, our industry has devised different architectural patterns that are effective at decoupling implementations while providing scalability and performance. The Reactive Manifesto describes the goals of such an architecture with a prescription for Reactive Systems.
Unfortunately, most projects don't begin by utilizing this architectural pattern because the overhead of effort required to get started doesn't outweigh the immediate need to show some value for a customer to prove the need for the existence of the App. And thus begins the never ending cycle of prototypes that become MVPs that morph into businesses that then require some eventual rewrite in order to scale the business.
Using the TAO, we want it to be easy to begin building Reactive Systems from the start without additional overhead. By achieving this we can avoid entirely or greatly reduce the introduction of technical debt without the added cost of time.
This creates several Goals for the TAO:
- Simplified Adoption of Reactive Message-driven Apps
- Business Logic code that can be executed anywhere in the System
- No distinction enforced by the framework within the code that it executes on client, server, embedded, or in a data pipeline
- Program by Contract with a Dynamic Interface Definition Language (IDL)
- Apps have Integration built-in
- System-wide Aspect-Oriented Programming (AOP)
- The Last Architecture you have to adopt with confidence
3. Codify Software Product Descriptions
The TAO was born out of a way to describe Software Requirements to Engineers that ensures all aspects of the desired system were taken into account when designing the User and System Interfaces.
The most common complaints about Engineering Teams are:
- the app is poorly made and doesn't meet our requirements
- they're taking too long to build it
The primary source of these 2 complaints is ineffective descriptions of the desired outcome in the form of Software Requirements.
We want the TAO to be a primary tool used for describing software as a Simplified Grammar to Codify the description of the desired Application in order to:
- make Product Managers better by:
- giving them a device that is easy to learn
- getting them closer to the code elements of an App
- identify gaps in requirements before planning or implementation
- reduce the verbosity required by BDD
- make Engineering Teams better by:
- being on the same page with Product Managers
- giving them a device to elicit requirements effectively
- communicating relevant implementation decisions better
This leads to several Goals:
- Engineers, QA & Product Managers have a Shared Grammar making it easy to:
- Have access to all aspects of a feature in planning before execution
- Effectively discuss and debate implementation details during planning
- Provide a Meta-language for Product Description that embeds itself into the code (Traceability)
- Product Managers can create Artifacts that generate starting point boilerplate code
- Self-documenting code
4. Empower Developers with Flexibility of Technology Choices
Finally, there are a lot of frameworks in the eco-system that are designed to make Rapid Application Development (RAD) easy to adopt. Generally these frameworks provide tooling support to add and make changes. But these frameworks have several flaws:
- Locked into rigid development paradigms unable to evolve with the pace of modern technology systems and patterns
- Not built as Reactive Systems that scale across Micro-service architectures or no discrete way to integrate Message-oriented data flows
- Dumbing down of data store technologies to the lowest common denominator making the specific choice indistinguishable from the others
- Difficulty to upgrade and support major versions without a responsibility from the maintainers because it's "Open Source" (buyer beware)
- Variance in the mechanism for extension points amongst frameworks tying the implementation code to the framework
The TAO provides a frameworkless framework approach. The TAO's programming paradigm could itself be considered a framework, but motivation behind the TAO is to support and encourage the ability for developers to choose any technology or other framework they desire to implement their Apps while gaining all of the benefits of using the TAO.
The Goals that come from this motivation are:
- A Framework that doesn't lock Developers into Technology Choices
- Provide powerful tooling to support and speed development
- Framework that encourages choosing the right tool for the job by enhancing the distinctions between technology choices and allowing them to live side-by-side seamlessly
- Fully Configurable or Configuration by Convention, the choice is up to the Developer
Full Goal Matrix
|1.||Motivation: Build Apps in a Way that allows them to Evolve effectively|
|1.||Applications are always composable and decoupled|
|2.||Build Apps like Building on a Platform|
|2.||Motivation: Make it Easy to build Apps with good Architectural Foundations|
|1.||Simplified Adoption of Reactive Message-driven Apps|
|2.||Business Logic code that can be executed anywhere in the System|
|3.||Program by Contract with a Dynamic Interface Definition Language (IDL)|
|4.||Apps have Integration built-in|
|5.||System-wide Aspect-Oriented Programming (AOP)|
|6.||The Last Architecture you have to adopt with confidence|
|3.||Motivation: Codify Software Product Descriptions|
|1.||Engineers, QA & Product Managers have a Shared Grammar|
|2.||Provide a Meta-language for Product Description that embeds itself into the code|
|3.||Product Managers can create Artifacts that generate starting point boilerplate code|
|4.||Motivation: Empower Developers with Flexibility of Technology Choices|
|1.||A Framework that doesn't lock Developers into Technology Choices|
|2.||Provide powerful tooling to support and speed development|
|3.||Framework that encourages choosing the right tool for the job|
|4.||Support Fully Configurable and Configuration by Convention|