Building and Accelerating Enterprise SaaS solutions

The Challenge

Anyone designing, architecting, building, testing, and releasing enterprise SaaS offering, with the potential of touching every single American, on an accelerated timeline understands this is not a simple task.

Hundreds of different teams or companies will find hundreds of ways to plan and deliver on bespoke missions, but broadly speaking, there are two extremely opposing views and approaches. Which side of the spectrum, your chosen software development direction falls on is based on a number of factors:

• Who in the company is making technical decisions?
• How is the company’s organizational structure functioning?
• Are the highest level decisions made by CEO, CPO, CTO, CMO, or collectively? 
• Are the financial conditions and restraints driving most or some of the decisions?
• Have the design, product research, and competitive analysis been completed?

The Casebook Philosophy

Of the two team-building approaches, the first option is hiring a few world-class architects and an army of developers. Also known to everyone in the modern world as outsourcing. The second option is hiring a dozen talented independent senior software engineers and providing them with a collaborative and inspiring environment where every individual can excel his/her own maximum potential.

Here at Casebook PBC, we chose the latter! We chose the latter because of our belief in building for the future rested on creating the strongest possible knowledge and experience foundation, allowing us to accelerate our growth.

Growth and Decision Making

While Casebook has a decade long and expansive knowledge, experience, and understanding in person-centric Child Welfare software solutions, our own software needed rethinking and re-platforming for a new age of AI and containers. Growing beyond our roots in child welfare while adapting to the new CCWIS meant re-platforming and redeveloping a modern Human Services platform. With this new software architecture and design-opportunity came endless questions and an even longer list of decisions.

As we embarked on this ambitious multi-year effort, some decisions were easier than others. Hiring top talent was an easy decision. Likewise, selecting Microservices architecture, Amazon Web Services (AWS), Cloud Architecture Security models, RESTFul & JSON APIs, Kafka, Elasticsearch, Kubernetes, and automated CI/CD processes were also fast and easier. 

Meanwhile, the following areas were much slower with days, weeks, and even months spent on research and comparison.

• Programming language – comparing talent pool availability
• Design Driver Development (DDD), Functional Development – the potential effect today’s work will have on adding a new microservice, new external integration, new client, new technology months and years in the future
• Test-Driven Development (TDD) – Merging TDD with a fanatical drive to optimize proved challenging in its early days
• Agile Methodology variation and adaptation – Marrying, balancing, and prioritizing short term feature needs with a sound architectural and software design for years to come
• ETL & Data Warehousing – Defining a foundation that provided the flexibility and configurability needed in a low-code/no-code approach with the ability to derive insights from data warehousing, reporting, and data mining forced us to face the high complexity required by an industry-changing data model
• SQL, No-SQL, Document-based, or GraphDB repository layer – the more you learn and understand this domain, the more questions you will have. At one point you will have to trust your instinct, but remember where and what state and format is the data before injecting it into your system and what are use-cases including for AI, ML & NLP applications
• Single Sign-on (SSO) – While there are many market darlings in SSO, the cost/benefit scenario to end customers can often be challenging Cloud architecture based SaaS solution clearly delivered substantial growth in this area. Many vendors are now providing great open-source and Federated integration solutions.  

Many other decisions required detailed evaluation and comparing the pros and cons between three, four, five, or even ten options in some cases before we made the selections. 

A number of articles can be written on each of these topics listed here while making very strong arguments for and against the eventual winner. 

Going into the details how each decision was derived are the topics for the future, but it is essential to remember that in addition to delegating ownership and responsibilities to groups, teams and individuals, having open conversations and inclusivity is more important to deliver year to year goals that it is to win every argument. 

The Takeaway

Keeping core concepts, like security, programming standards, and Casebook mission, has given us general direction and principals. But culture and results are based on more than just picking Java or Go or Clojure or Gitlab or Jenkins; they are a mosaic of individual team member manifestations and their personal interpretation and socialization of Casebook’s vision. 

By designing and expanding the best possible team from the start, we were able to face many of the questions and challenges leading to a great platform head-on. And now that we have established a solid foundation for our offering, we are looking forward to an accelerating ability to move the market forward and grow with tomorrow’s demand with new flexibility.