2016-09-02

Beauty of #microservices: part 5 defragmentation of enterprise data model

1 Introduction


This blogpost is inspired by several blogposts about microservices and it is based on the blogpost [REF1] “Architecting #cloud-friendly application architecture #apparch (inspired by #microservices)” http://improving-bpm-systems.blogspot.ch/2015/04/architecting-cloud-friendly-application.html which uses other blogposts about microservices http://improving-bpm-systems.blogspot.ch/search/label/%23microservices

See also the previous blogposts of “Beauty of #microservices” series.

2 Unfortunate historical fragmentation of enterprise data


In modern enterprise computing environments, an enterprise data model (as a set of business-entities defined at the enterprise level) is, usually, an utopia. Enterprise data are spread among many existing applications that master some attributes of some business-entities. Also some business-entities are duplicated (usually, partially, by some fragments of them) among existing applications.

Because each of those applications (in-house developed, SaaS-based, PaaS-based, intact COTS, modified COTS) has its own lifecycle, the enterprise data model is far from the reality and complex data integration is mandatory to keep the integrity of the enterprise data.

Each new application has its own data and uses data from other existing applications. Thus, an application data model comprises some views on some business-entities from the enterprise data model. However, in such an application data model only some attributes are under control of the application.

If an application has to use data from several other applications then the evolution of some application may have a destructive effect on some other applications – typical “Château de cartes” anti-pattern.

3 Enterprise data model must be flexibility-driven not legacy-held


Ideally, an enterprise data model must
  • easy to evolve (by definition)
  • be service oriented so data can be accessed only via API (this its fragments can be joint up together even not sitting in the same database)
  • implement total versioning for some business-entities (to cover the enterprise lifecycle)
  • cover all the types of business-entities
    • transactional data (your business-specific and business-critical data)
    • reference data (taken from other sources and business-parties)
    • operational data (about how the work has been done)
    • reports
    • analytics data
    • records
    • documents
    • media
    • social

There are several techniques to move to this ideal.

Make some functionality enterprise-wide as a Corporate Unified Business Execution (CUBE) platform (see http://improving-bpm-systems.blogspot.ch/2015/10/enterprise-patterns-peas-example-cube.html ). Thus an individual application comprises only business-specific functionality. For example:

  • security management (identity, authentication and authorization)
  • content and knowledge management
  • software factory
  • reporting and analytics
  • business process management
  • records management
  • etc.

Make explicit data update processes – see the pattern “Practical process patterns: Synchronisation Of Sources (SOS)” http://www.slideshare.net/samarin/practical-process-pattern

Use some specific characteristics of your enterprise.

4 Adding flexibility


The classic “point-to-point” scenario is that a solution can read some data from some applications via storage-centric API or asset API or stor-API. Actually, those data are application-specific views on some enterprise business entities, e.g. “ClientERP BE” is the business entity CLIENT as it is defined in an ERP. Of course, in this sensation, the solution 1 strong depends on the evolution some other applications.


Another classic “data-access-layer” scenario is to use a microservice aggregate all the application-specific views in a read-only business entity.


The ability of microservices to have their own persistence store (which may be just a table in a common database) is very useful to implement a small extension of an business-entity. The same technique may help to avoid customisation of COTS products. This is a safe way to mode to an ideal enterprise data-model.


With some efforts (mainly for externalising some business logic), read-only APIs may be transformed into read-write APIs. If a business-entity uses more than one underlying applications then a “data update process” is necessary to implement a multi-phase commit.


If it is possible to externalise the business logic then some functionality-centric API or business API or func-API may be implemented.



5 Conclusion


With the use of microservices and other technologies, an enterprise data model may:

  • become always up-to-date and
  • evolve with the speed of agile development.

Thanks,
AS

Posted by Alex at 15:52
Labels: , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)