Delivering Foundational BUSINESS Agility TODAY
AAF Data is the crucial first layer — business entity data modeling and persistence — of the Adaptív Application Foundation (AAF), which can accelerate and empower your people, excite your stakeholders, and delight your customers.
TODAY?
Yes, put 30 carefully-crafted database tables and a high-performance API-based CRUD microservice in your own environment in minutes, not weeks or months.
WHY IS DATA DESIGN IMPORTANT?
If your primary concern is:
Executive Leadership (Founder, CEO, Board Member)
Our clear, clean, complete, and consistent data design can immediately make your teams more productive, your processes more efficient, your customers happier, compliance easier to achieve, and your organization better able to capitalize on new opportunities and to address new challenges.
Keep your board happy, retain top talent, train AI models quickly and easily, and enjoy rich, accurate, up-to-date, and consistent data and visualizations (dashboards, KPIs, etc) to “steer the ship“, support decision-making, and make your life easier.
Budget/Financial (CFO, Controller, etc)
Teams often spend weeks or months creating database tables and services just to read and write data. Depending on team size, this can easily cost $25,000 ($80K annual salary / 12 months * 4 team members = $26,667) or more, depending on the number of tables, team size, etc, while also delaying the start of work on the functionality that will actually generate revenue (lost opportunity).
AAF Data dramatically reduces both cost and time to value (TTV), while supporting clear, clean, complete, and consistent data, which is vital to reporting, analytics, legal compliance, etc.
Product (VP Product, Product Owner, etc)
Help your teams focus on building the functionality that you know will attract and please customers, while avoiding the pitfalls that can easily jeopardize future timelines.
Engineering/Technical (CTO, CIO, VP/Director Engineering or Software Development, etc)
Help your teams to deliver innovative external product capabilities and internal digital initiatives, despite budget constraints and increasing demands from the business. Reduce total cost of ownership (TCO), while ensuring that digital solutions are built securely and sustainably.
Team Leadership (Technical Lead, Technical/Application/or Solution Architect, Project Manager)
Use your influence to improve team health and productivity, to deliver predictably, and to attract and retain great talent. Even if your team is experienced at data design (most aren’t, and underestimate its challenges, vital importance, and long-term impact), it’s not their favorite thing to do. Use AAF Data to check it off your list so that they can move on to “the fun stuff”, confident in our 20+ years of world-class data design experience and ground-breaking data modeling approach.
Take a quick (6 minute) look at our new web-based data Modeler, which we’re already using to add more database tables to the free, Open Source AAF Data product.
We want to make AAF Data’s revolutionary capabilities available to everyone, regardless of technical level or available resources, so that you can start collecting and benefitting from AAF Data’s clear, complete, consistent data sets and capabilities without delay! So schedule a free consultation with our implementation partners Cygnus Technology Services for help with evaluating your planned or existing data structures as well as product implementation, data migration, product customization, training, and support.
Or get the product directly from GitHub, including a detailed Getting Started README section, and pull down the ready-to-run AAF Data service Docker images from Docker Hub.
Today, AAF Data is:
- A standalone set of
- 30 carefully-crafted business entity models,
- PostgreSQL database creation scripts for roles, schemas, tables, functions, and
- Scripted lookup/reference data,
- A Dockerized, RESTful business entity data microservice (EDM) providing
- Basic entity data CRUD operations
- Create,
- Read,
- Update,
- Delete,
- Keyword text search, and
- SwaggerDoc OpenAPI application programming interface (API) documentation.
- Basic entity data CRUD operations
- A Dockerized, RESTful system data service (SDS) providing the capability to:
- Create new business entity definitions,
- Clone existing definitions,
- Create new business entity attributes,
- Associate business entity attribute(s) with business entity definition(s),
- Publish entities, attributes, and associations, creating corresponding new database schemas, tables, constraints, indexes, etc,
- SwaggerDoc OpenAPI application programming interface (API) documentation
- A Progressive Web Application (PWA) business entity modeling service (EMS) with a custom EntityTable HTML5 Web Component, providing a lightweight, easy-to-use interface
- SwaggerDoc OpenAPI application programming interface (API) documentation
Soon AAF Data will also include:
- Terraform scripts for creating AWS infrastruture and deploying the AAF Data services to the cloud,
- JWT helper functions (encode/decode),
- CRUD operation event publishing.
AAF Data Rules
30 Carefully-Crafted, Ready-to-Use Business Entities
The complete set of business entities and their detailed descriptions can be retrieved using the [BASE_URL]/entityTypes/EntityType API endpoint, like an online, always up-to-date data dictionary and includes:• EntityTypeDefinition*• EntityTypeAttribute*• EntityTypeDefinitionEntityTypeAttributeAssociation*• EntitySubtype*• EntitySubtypeHierarchy• EntityType• Language, e.g. English• Locale, e.g. en-US• GeographicUnit, i.e. country, state, province, etc• GeographicUnitHierarchy, e.g. U.S. (parent), Texas (child)• Currency, e.g. USD• Periodicity, e.g. hourly, daily, weekly, monthly, quarterly, annually, etc• PostalAddress (ready for internationalization)• Organization, i.e. legal organization, e.g. corporation, limited liability company, etc• OrganizationalUnit, e.g. department, office, region, etc• OrganizationalUnitHierarchy, e.g. Eastern Region (parent), NYC Office (child)• Person (ready for internationalization)• Employee, i.e. associating a Person with an Organization• LegalEntity (a legal abstraction representing a Person or an Organization)• InternetDomainLabel, e.g. www, dst, com, etc• InternetDomainLabelHierarchy (to model structures like www.dst.com)• TelephoneNumber (ready for internationalization)• EmailAddress (leverages the InternetDomainLabelHierarchy)• UniformResourceIdentifier (identifies a resource and optionally how to access it)• InformationSystem (an integrated collection of digital assets for collecting, storing, and processing data)• ContentItem (an individual instance of information that is delivered to an audience via a specific medium for the purpose of expression, communication, or commerce)• ContentItemGroup (a many-to-many grouping mechanism for ContentItems that may be related by subject, audience)• ContentItemGroupContentItemAssociation (associates zero or more ContentItems with a ContentItemGroup)• Keyword (a significant attribute value for a given entity instance, e.g. the value Red for the attribute Color that can be used as a tags/hashtags, search engine input, etc in order to establish/clarify identity, clarify meaning, organize and/or classify, and that are often used to request information, for navigation in a hierarchy ,or to search)• KeywordGroup (a many-t-many grouping mechanism for Keywords that may be related by purpose, subject, etc for navigation, search, etc)• KeywordGroupKeywordAssociation (associates zero or more Keywords with a KeywordGroup)
* “Origin” entity, used to define business entities
A set of common business entity attributes are part of each business entity definition and corresponding database table, etc. These business entity attributes and their descriptions can be retrieved using the [BASE_URL]/entityTypes/EntityTypeAttribute API endpoint, like an online, always up-to-date data dictionary and includes:• Id bigint• Uuid uuid• EntitySubtypeId bigint• TextKey varchar• ResourceName varchar• Ordinal bigint• IsActive boolean• CorrelationUuid uuid• Digest varchar• CreatedAtDateTimeUtc timestamp• CreatedByInformationSystemUserId bigint• UpdatedAtDateTimeUtc timestamp• UpdatedByInformationSystemUserId bigint• DeletedAtDateTimeUtc timestamp• DeletedByInformationSystemUserId bigint
Clear, Clean, Consistent, and Complete Business Entity Attributes
Ensures that everyone, including report writers, data analytics teams, data scientists, etc, not just the engineers can quickly and easily understand the data structures and that all the entity data your teams need to spin up reports and dashboards, to answer important questions, to train AI models — all of it — is captured from Day One. Don’t fall for YAGNI when it comes to your data. You are going to need it, and not having it is going to be very expensive and time consuming. Here’s why …
Clear, Consistent Naming
These business entity and entity attribute names, data types, Pascal case, etc are intentional, carefully chosen, and NOT to be altered.
When naming entities and attributes, we avoid acronyms and abbreviations, and we:• Strive to think carefully about what they really represent,• To “call things what they really are“, and• To be specific, e.g. CreatedAtDateTimeUtc
• EntitySubtype
• GeographicUnit
• GeographicUnitHierarchy, etc
represent scripted (canonical) lists of options like an entity’s subtypes, e.g. GeographicUnit’s Country, U.S. State, Province, etc.
Scripted Reference/”Look-Up” Data, Which Is the Same in Every Environment
Standard “Unknown” and “None” Values
• Unknown (Id = -1) and
• None (Id = 0)
are standard EntityType and EntitySubtype values indicating a currently unknown/to be determined or an inapplicable entity or entity subtype value, respectively.
The custom database roles:
• AafCoreOwner
• AafCoreAdministrator
• AafCoreModeler
• AafCoreDataReadWrite
• AafCoreReadOnly
are to be used appropriately (as designed and demonstrated in this project) to reduce over-permissioning and to improve data security.
Custom Database Roles
Database Schema Partitioning
Each entity’s database table is partitioned using a corresponding Postgres schema, e.g. “Organization”.”Organization”.
AAF Data Features
API-Based Data Persistence, “Soft” Deletes, and No Direct Table Access
Persists and retrieves business entity data via its API, which calls low-level POST, GET, PATCH, and “soft” DELETE database functions to ensure data integrity and performance — NO direct table access.
Consistently follows RESTful style and best practices.
RESTful Best Practices
Standard HTTP Response Codes
Returns standard and appropriate HTTP response codes, e.g. 200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Internal Server Error, etc.
Accepts and returns structured JSON resource/entity data in HTTP request/response bodies as specified for each business entity.
JSON Request/Response Bodies
Entity (Resource)/Process Partitioning
Includes entities in the request URL, e.g. /entities/organization/1234, to partition low-level resource/entity operations from future high-level process invocation, e.g. /processes/InformationSystem/RegisterInformationSystemUser/.
The business entity microservice (BEM) validates each HTTP request using a JSON Web Token (JWT) mechanism with optional cryptographic signing and encryption capabilities.
HTTP Request Validation
Containerized
Services run in Docker containers, available from DockerHub.
We have ORMs, Repository pattern, and DTOs. Isn’t data a solved problem?
In a word, no.
None of these technologies and tools address or encourage good data design, and all of them lead us down ever more compromising paths that result in unnecessary and expensive code creation and maintenance and poor data design and performance and that shift data operations from the database server, where they belong, to the service layer, forcing all kinds of anti-pattern trade-offs.
“Data is absolutely foundational to information systems. If the data ain’t right, ain’t none of it gonna be right. At the very least, teams will spend lots of unnecessary time coding around or in place of things that could and should have been established clearly in the data layer with just a little thought and discipline.
The data layer — database roles, schemas, tables, columns, data types, indexes, constraints, functions/stored procedures, Structured Query Language (SQL) scripts to create all this structure and to provide reference data, etc — is there to work for us, not the other way around. It’s important that we understand and use the right tools for a given job and that we wisely invest the time to design and create a structure that will pay dividends for years. Yes, this is not only possible but absolutely crucial to your long-term success and that of the organizations you serve. Use the data layer to model business entities and relationships and to persist their data. Design it to collect a complete, consistent data set from day one rather than only adding data elements when they’re asked for.“
Object Relational Mappers (ORMs)
- Are entirely unnecessary, if database column names, service property/attribute names, and user interface (UI) widget field names are all derived from a model and are therefore the same in the data layer, service layer, and presentation layer.
- Don’t typically encourage custom roles with different privileges, e.g. database owner, database administrator, read/write, read-only, etc, an omission that can easily result in dangerously overprivileged database access and compromised data security.
- Don’t encourage thoughtful entity or attribute naming, which is vitally important and should therefore be intentional. In AAF Data we wisely invest time thinking carefully about names or adopt naming established by those who have thought carefully in the past.
- Don’t encourage consistency, completeness, or specificity. In AAF Data we name attributes clearly, e.g.
CreatedAtDateTimeUtc, in consideration of our fellow “downstream” developers, report writers, analytics developers, and data scientists, who need to know what to expect without the need to create and maintain a separate data dictionary. - Do encourage (and exist in order to facilitate) data entity definition in the service layer — a dangerous anti-pattern that combines:
- Business data entities that represent the nouns — the persons, places, and things — that our information systems are intended to manage,
- Business processes that represent the verbs — the actions that operate on and orchestrate the interactions of these entities, and
- Business rules (or “decisions”) are the logic and conditions that inform and constrain these processes.
- Don’t typically “layer” data validation by leveraging the database server’s built-in and highly efficient constraints, referential integrity, etc.
- Don’t seem to understand that any system can be modeled using:
- Business Entities (e.g. Person, Organization, etc, which can contain scalar text-based and numeric data, as well as foreign key references),
- Associations (e.g. Employee, which associates a Person with an Organization using their Id values as foreign keys), and
- Hierarchies (e.g. OrganizationalUnitHierarchy, which can represent hierarchical structures using OrganizationalUnit Id foreign key values as ParentOrganizationalUnitId and ChildOrganizationalUnitId)
- Don’t discourage poor attribute grouping that often results from the lack of a clear business entity concept, leading to data attributes that actually belong to several different entities being thrown together in a single database table.
- Discourage the use of database stored procedures/functions. There’s a lot of value to being able to essentially conduct an application’s data operations through the same stored procedure data access layer called from the service layer, and there are certain things that can only be done server side in the database.
The result of all of this is that unexamined, unchallenged, poor data design gets “baked into” the data layer every day and then impedes progress and costs the organization, its stakeholders, and its customers money and time forever, rarely if ever getting fixed because it’s in the foundation, and changing the foundation can put the whole Jenga stack at risk.
It is the mission of AAF Data to provide a clear, complete, consistent, and performant alternative to all of this.
AAF Data Screenshots
