Reference no: EM132249423

PLEASE READ and REVIEW the BELOW PARAGRAPH.  Depending on the concepts of Kaizen, Design Thinking, Business Process Management, please write down your comments on it, in one page.

Enduring Engineering Practices

One side effect of the increased pace of technological innovation is a repeating expansion and contraction pattern. When an innovation appears that fundamentally changes how we think about some aspect of software development, the industry races to adopt it: containerization, reactive frontends, machine learning and so on. That's the expansion phase. However, to make this "new thing" truly effective requires figuring out how to apply enduring engineering practices to it: continuous delivery, testing, collaboration and so on. The contraction phase occurs as we ascertain how to use this new capability effectively, creating a firm foundation to allow the next explosive expansion. During this phase we learn how to apply practices such as comprehensive automated testing and the scripting of sequences of recurring steps within the context of the new technology. Often, this goes hand in hand with the creation of new development tools. While it may seem that the introduction of a new technological innovation alone advances our industry, it's the combination of innovation with enduring engineering practices that underpins our continued progress.

However, at the opposite end, engineering practices also sustain on the dodge upon microservices. A defining characteristic of a microservices architecture is that system components and services are organized around business capabilities. Regardless of size, microservices encapsulate a meaningful grouping of functionality and information to allow for the independent delivery of business value. This is in contrast to earlier approaches in service architecture which organized services according to technical characteristics. It has observed a number of organizations who've adopted a layered microservices architecture, which in some ways is a contradiction in terms. These organizations have fallen back to arranging services primarily according to a technical role, for example, experience APIs, process APIs or system APIs. It's too easy for technology teams to be assigned by layer, so delivering any valuable business change requires slow and expensive coordination between multiple teams. One must caution against the effects of this layering and recommend arranging services and teams primarily according to business capability.