Legacy source record · not a published Labs artifact
Anant Platform Playbook
This material is preserved from the WordPress site for review. It is noindexed, may contain dated language, and does not count toward the five-artifact launch gate.
Anant Platform Playbook
At Anant, we have been building business platforms since 2010. Today, our expertise is in global, real-time, distributed data platforms that connect all aspects of a modern enterprise. This Playbook comes from our experiences earning that expertise. It’s a set of best practices and a framework for creating, maintaining, and operating a modern enterprise business platform with a real-time data & analytics platform connecting it all.
Platform Principles
1. Contexts
2. Responsibility
3. Approach
4. Framework
5. Tools
Framework Principles
6. Distributed
7. Realtime
8. Extendable
9. Automated
10. Monitored
Approach Principles
11. Setup
12. Training
13. Administration
14. Customization
15. Knowledge
Platform Principles
The people, processes, information, and systems overlap across responsibility areas in an organization.
Having a framework allows us to use the best practices but the freedom to switch things out.
Templates and tools help us save time and be consistent.
1. Contexts
Contexts – People, processes, information, platforms, in that order.
By prioritizing in this order:
- People – People are more important, so the user experience is paramount.
- Process – Processes are more important data. Business needs are greater than which database you use.
- Information – Information is more important than the platform. Platforms come and go, but information can transform and go anywhere.
- Platforms – Platforms serve the needs of information, which serve the needs of processes, which serve the need of people.
Technology serves business needs. Not the other way around. If you help the user achieve their goals, the platform is good.
2. Responsibility
The people, processes, information, and systems overlap across responsibility areas in an organization.
Think of this as a way to organize the company as a set of “microservices” that are leveraged across different parts of an organization.
Though there may be different responsibility areas, there is only one business platform.
3. Approach
Having an approach allows us to manage systems long term.
All platforms should be tracked and managed using a standard approach for setup, training, administration, configuration, and knowledge management.
Here are the suggested minimum viable responsibilities for managing a technology platform.
- Setup – Setup procedures should be documented, scripted, and then automated.
- Training – Training materials should available or referenced in a central place.
- Administration – All administrative operations should be documented, scripted, and then automated.
- Customization – All customization or special configuration should be documented, and part of a devops process.
- Knowledge – All knowledge should be kept up to date as part of each sprint.
4. Framework
Having a framework allows us to use the best practices but the freedom to switch things out.
All components of the framework should be:
- Distributed – All components should be distributed.
- Realtime – All components should be realtime reactive platform.
- Extendable – All components should be extendable and not closed.
- Automated – All operations with data and dev should automated.
- Monitored – All systems should be monitored with metrics and logging.
5. Tools
Templates and tools help us save time and be consistent.
Instead of reinventing the wheel, leverage tools and templates that already exist. There may have been someone else who has encountered the same business problems.
Don’t reinvent the wheel, use:
- Spreadsheets – Using web grid / online spreadsheets allow team members to organize critical information.
- Documents – Using online document editors allow team members to brainstorm / document processes easily.
- Kanban Boards – Kanban boards, regardless of which software you use allows you to visualize work in progress.
- Wiki – Wikis are great for storing the most critical information in a way that is easily accessible.
- Doc Sites – Doc sites are like Wikis but have the benefit of being released /published via source control.
Framework Principles
6. Distributed
All components should be distributed so that it can scale and be available, all the time, to all users.
- Data storage is distributed and replicated for high traffic and availability.
- Queues or streams are distributed or sharded for high traffic and availability.
- Stream processing should be distributed for computational scale, speed, and availability.
7. Realtime
All components should be realtime or reactive platforms.
- Data storage should respond to all read and write requests at high speeds.
- Queues should respond to all read and write requests at high speeds, without bottlenecks.
- Stream processing should handle queue processing and data storage/retrieval at high speeds, without bottlenecks.
8. Extendable
All components should be extendable and not closed.
Don’t reinvent the wheel if you can help it by using existing components that are extendable.
- Cloud native Software, platforms, and infrastructures should be leveraged if and only if they can be extended through APIs, or modules.
- Alternatively commercial open source software or platforms should be leveraged for ultimate portability and no vendor lockin.
- Pure open source should be used if no commercial or cloud options are available either as a managed service or as a commercially supported offering.
9. Automated
All operations with data and dev should automated.
- Development Operations (DevOps) should be implemented for continuous integration and continuous delivery (CICD).
- Data Operations (DataOps) should be implemented for automated data pipeline management.
- All infrastructure, software configuration, and software maintenance should be automated.
10. Monitored
All systems should be monitored with metrics and logging.
- All systems should have baseline Service Levels that are monitored as metrics.
- All systems should emit logs that are configurable at different levels.
- All systems logs should be aggregated and retained in an index for quick correlation and investigation.
Approach Principles
11. Setup
Setup procedures should be documented, scripted, and then automated.
- Understanding current / future needs.
- Mapping a next viable architecture.
- Deciding on Infrastructure.
- Install & Stress Test.
- Orchestration Automation.
- Continuous Integration & Delivery.
12. Training
Training materials should available or referenced in a central place.
- Discovery: Understand skill gaps.
- Curriculum Planning.
- Architecture Training.
- Implementation Training.
- Operations Training.
- Ongoing Mentoring.
13. Administration
All administrative operations should be documented, scripted, and then automated.
- Service Management.
- Service Transition.
- Incident Management.
- Data / Disaster Recovery Plan.
- Continuous Monitoring.
- Continuous Testing.
14. Customization
All customization or special configuration should be documented, and part of an automated devops process.
- Self Service Process.
- Testing Environments.
- Service Transition.
- Service Strategy.
- Continuous Testing.
- Change Management.
15. Knowledge
All knowledge should be kept up to date as part of each sprint.
- Platform Architecture.
- Platform Operations Runbook.
- Platform Implementation Guide.
- Issue Resolution Knowledge.
- Public / Internal Knowledge Sources.
- Continuous Knowledge Creation.