- Application monoliths are evils, but having too many microservices sounds like creating an (unknown) evil as well.
- Everything has to be re-developed.
- Microservices will create a huge backlog for our agile team.
- Microservices? They are neither architecture nor architectural style – just a technical stack.
MicroService Architecture (MSA) bring two major concepts:
- microservice as a unit-of-functionality, unit-of-deployment and unit-of execution with the same boundaries, and
- assembling a whole application from microservices of different origins: off-the-shelf (commercial and FOSS), brought, rented, built, provided from SaaS, PaaS, APaaS, etc.
Firstly, it is necessary to think about any application as a set of the following artefacts
- Events
- Roles (actually, access rights management)
- Rules (or decisions)
- Business objects – data structures
- Business objects – documents
- Human activities (or screens or interactive services)
- Automation activities (or scripting fragments or automation services)
- Coordination
- Audit trails
- KPIs
- Reports
- Explicitly
- As a set of microservices
- Via APIs
- With versioning
- By a specialized OTS tool, e.g. data structures are handled by a database, processes are handled by a BPM-suite tool
- In a Domain Specific Language (DSL), e.g. BPMN for processes, DMN for rules
- Over its whole life cycle
- Coordination as explicit and machine-executable processes via a BPM-suite tool
- Roles via an access management tool
- Documents via an ECM product
- Automation fragments as scripts in an interpretive language and execution robots
- Audit trail and reports via BI tools
- etc.
- technological pool for generic off-the-shelf products; their functionality is available via APIs
- enabling pool for services, microservices, tools which are a) specific for the particular organisation and b) potentially reusable within organisation; their functionality is available via APIs
At the result, we got a corporate unified business execution platform which standardise and simplify core elements of the corporate-wide computing system. For any elements outside the platform, new opportunities should be explored using agile principles. These twin approaches should be mutually reinforcing:
- The platform frees up resource to focus on new opportunities while successful agile innovations are rapidly scaled up when incorporated into the platform.
- An agile approach requires coordination at a system level.
- To minimise duplication of effort in solving the same problems, there needs to be system-wide transparency of agile initiatives.
- Existing elements of the platform also need periodic challenge. Transparency, publishing feedback and the results of experiments openly, will help to keep the pressure on the platform for continual improvement as well as short-term cost savings.
Thanks,
AS
Posts
