Database Planning
Architectu Maturity Model Current and 2015 Target
AgendaThe Agenda is to brief about
What is in Level IV MaturityAS-IS ArchitectureTo-be
Architecture
What is in Level IV MaturityA SaaS application must have 3
attributes, Scalable, multi-tenant and configurableScaling:
Maximizing the concurrency: Optimizing locking duration (NIO),
statelessness, shared resources, caching, partitioning Large
databases Same Db Server is shared with other
ApplicationsMulti-tenancy: Sharing of resources across tenants, but
able to differentiate data belonging to different
customers.Configurable: Must provide configurable Meta data for
customization
What is in Level IV MaturityHost Multiple customers on Identical
Load Balance InstancesThe Data of each customer must be separate
Configurable Meta Data for Customizing ExperienceScalability: No
Instances can be able to Increasable or decreasable with
demand.Changes of application can be Rolled out to thousands of
tenants as single tenant.Meta Data Services includes, UI &
Branding, Workflow & Business Rules, Access control
What is in Level IV MaturitySecurity Services include:
Centralize Authentication and Authorization, SSO, Roles and
Permissions (RBAC)Application design needs statelessness, with
necessary user or session data must be stored in Client side or
Centralized mannerAsynchronous I/O Operations, Maximize Database
operations concurrency. Shared Services: Account activation,
provisioning, usage and metering
AS-IS Architecture
AS-IS ArchitectureUI & Backend not developed to configure
Meta Data of Tenant The Backend is Good in Addressing Separations
of Concerns and Modular. But still it is a Monolithic
ApplicationMemory is shared between all Modules. Application runs
as Single Process.Updating Application at RUN time is not possible
until we redeploy WAR file all the time. i.e, Hot deployment is not
possible. It is good for Frequent changes but not for Minor
changesAdding a New Feature or New Module requires some degree of
coupling.
AS-IS ArchitectureFollows Request/Response Mechanism. So
Requests will be in Queue until previous request has processes and
gave response back. Not truly Highly scalable. Blocking IO and Not
Truly Asynchronous.As Team grows Co-ordination is Over ahead if
Product requires more features and functionalities.Database is
still based on Schema design.Dependency on ORM tools
To-be ArchitectureNeed to implement Event Driven Architecture .
Increase Loosely coupling by Introducing Event Bus in
Application.We need to separate application as Modules of Events
Producers or consumers.Event Generator process will not aware of
Subscribers existence Separate Read and Write Models and functions
and functionalities. Deploy each Process as separate service and
Integrate it with through Message Channel.Each Service must have
its own UI and database
To-be ArchitectureDesign Database Schema less as much as
possible.Write Application as StatelessIf services needs different
data formats then only we need ESB. Otherwise simple Message
Oriented Middleware
To-be Architecture Diagram
