Beauty of #microservices - enabling #BizDevOps culture

Everyone heard about the DevOps culture which refers to a set of practices that emphasize the collaboration and communication of both software developers and IT professionals while automating the process of software delivery and infrastructure changes.

Certainly, DevOps improves the time-to-market for digital solutions, but it spans only a down-stream part of the idea-to-solution value stream. To cover the whole value stream, any up-stream stumbling blocks must be removed.

An application architecture, which is built on microservices and their machine-executable coordination (e.g. by processes), enables a new BizDevOps culture by quick implementations of business ideas. (I think that ING has introduced the BizDevOps concept).

Microservice is a service with the same boundaries as
  • a unit-of-functionality (for Biz)
  • a unit-of-deployment (for Dev)
  • a unit-of-execution (for Ops)
Thus, an implementation of a business idea as a group of microservices will have no unnatural complexity and, therefore, its time-to-market will be short.



Other blogposts about microservices - http://improving-bpm-systems.blogspot.ch/search/label/%23microservices  

Beauty of #microservices - adding ASSEMBLE to BUILD or BUY or RENT

MicroServices Architecture (MSA) is changing the classic Buy or Build or Rent question.

With MSA, orgnisations may use an extra option - Assemble. This allows an organisation to select the best option for each service or microservices. For example:
  • Buy services and microservices from organisation's business partners
  • Build microservices for organisation's unique capabilities
  • Rent services and microservices from the commodity markets
  • Assemble all services and microservices into organisation's unique solutions


Other blogposts about microservices - http://improving-bpm-systems.blogspot.ch/search/label/%23microservices


Beauty of #microservices - #microservice architecture maturity model

This blogpost is inspired by the discussion https://www.linkedin.com/feed/update/urn:li:activity:6266622261210411008/

I can imagine an MSA maturity matrix:
  1. atomic microservices 
  2. compound microservices (a microservice with wide single responsibility is built from microservices with narrow single responsibility) 
  3. data-entry applications in MSA (interactive microservices, validation microservices, persistence microservices) 
  4. process-driven applications in MSA (coordination microservices, management microservices, etc.) 
  5. all former applications in a value-chain are in MSA(actually, no boundaries between applications)
  6. all former applications within an organization are in MSA
  7. all former applications in a supply-chain are in MSA
  8. all former applications in an ecosystem are in MSA

Please, see my blogposts on #microservices http://improving-bpm-systems.blogspot.it/search/label/%23microservices 



Enterprise patterns: SRAM

This enterprise architecture pattern Security, Risk and Architecture Mixture (SRAM) is just a picture.



Systems-level standardisation (example of smart cities)

Overall common city goals include, for example, sustainable development, efficiency, resilience, safety and support for citizen’s engagement and participation. However, an individual city will follow its own approach in smart cities programmes and projects.

The current implementation practices of smart cities are rather disjoint, namely:
  • smart cities projects are, primarily, local initiatives
  • smart cities projects are considered as technology projects
  • numerous smart cities interest groups are, primarily, clubs
  • efforts for development of common vision are insufficient
  • typical financing patterns are: the government is budgeting (to some extent) some cities which engage technological companies and the government is budgeting some technological companies (China’s approach) which engage cities.
As a result, there is no agreed basis for efficient and effective cooperation and coordination between different smart cities programmes and projects. They carry out a lot of duplication of work, developed solutions are not reusable, the same mistakes are repeated.

To address such negative phenomena, the IEC came up with a new approach to standardisation – the systems-level standardisation which provides the context for the traditional product-level standardisation. The systems-level standardisation is aim to achieve synergy between uniformity (availability of standard products) and diversity (ability to combine standard and proprietary products).

The systems-level standardisation (which is carried out by the IEC Systems Committee “Smart Cities”) will offer to smart cities programmes and projects commonly agreed and fully traceable deliverables, namely:
  • reference model (ideally, as an ontology), 
  • reference architecture of a smart city as a system,
  • typical use cases (how various actors interact with the smart city as a system); and 
  • set of existing and new standards for implementation of various capabilities of smart cities. 
The openness of those deliverables allows easily adjust the reference architecture to an individual city and re-use already available standard elements.

The smart cities vision can be illustrated by the following figure.
(CUBE means Common Urban Business Execution)

Being equipped by those deliverables, various smart cities programmes and projects can carry out efficient and effective cooperation and coordination among them thus
  • decreasing the total cost of smart cities programmes and projects, 
  • reduce the lead time; and
  • increase the quality of implementations.
At present, there are 4 Systems Committees (SyC):
  1. Smart Energy
  2. Active Assisted Living
  3. Low Voltage Direct Current
  4. Electrotechnical aspects of Smart Cities
And one System Evaluation Group (SEG):
  1. Smart Manufacturing

The IEC system-level standardisation is based on the IEC Systems Approach.