Software Architecture – A Background

Software Architecture – A Background

Sharing my experience in designing an app.

Typically, when we take up a business problem it always starts small and becomes overly complicated over a period of time. One has to start somewhere. In an agile world we cant anticipate all at once. However, we needed to break things up. My critical thinking is all about how will I make my  architecture simple and allow us to be more scalable and maintainable.

OK, before we jump into solution space let me layout the problem space`. If the problem is understood clearly then finding solution will be pretty simple. In my case the problem sounded daunting and that challenged me to make the solution modularized and simplified. Simplification is subjective. Also involves various trade-offs time to time.

At a high level, here is the problem at an abstract.

  • Our business is to provide SaaS based offering to our customers.
  • Our customers have customers (one of our users).
  • Our customers use different systems for their internal purposes. We dont provide any of those internal systems.
  • We work with our partners who are system vendors to extend their functionality to push the data to our site so that we can manipulate and translate the enterprise data can be consumed by our customers’ customers.
  • There are bunch of complex data that will be pushed up to the cloud.
  • The data will have to be cleaned up and translated so that our users can consume the data.

Who are the actors in the system

Software Ecosystem

Software Ecosystem

  • Our customers (another type of users) can login to the site and check how the data is being presented to their customers.
  • Our business operation folks (3rd type of users) who can login to the site and monitor the data flow, find out any issues with the data or system issues.
  • Our technical operation folks (4th type of users) who can monitor and adjust the load, thread counts, manage the queues etc.
  • Our business teams want to know any business metrics.
  • Our product management & experience design team want to know how the users are using the system and how to improve their experiences.
  • Architecture & development team wants to know how improve the quality of system. How to make system scalable, maintainable, secure, address the privacy concerns, adopt to the business changes, etc.
  • Our business partners want to know how to send the data, what kind of data can be sent, how the data is being shown to the external users, some key metrics and insight into the processing workflows, etc.
Phew! That’s a lot. Lets take it to the next level.In this blog, I am not certainly going to cover every thing, but I am planning to cover in deep our business operation folks requirements and how we approached to solve this problem.
Original Source Of this Blog : ModernAppArchitecture

I hope this has been useful for you and I’d like to thank you for reading. If you like this article, please leave a helpful comment and share it with your friends.

Leave a Reply

Your email address will not be published. Required fields are marked *