Define a continuous improvement process with EA models, practices

How enterprise architects fit in

You cannot make continuous improvement work without a strong enterprise architecture (EA) model-based approach to business process definition and management.

One school of thought says that continuous improvement should exist as a new mission for existing EA approaches, not a stand-alone process with tools and software. Continuous improvement simply formalizes how process feedback, a staple of EA-driven businesses, drives change to business processes.

In this approach, the organization relies on enterprise architects' well-established integration with software selection and development, so there is no need for new software quality tasks or tools to build out a continuous improvement process. Continuous improvement, at most, might reveal a lack of organization in the way the organization manages feedback. EA teams shouldn't need much additional help from software or changed practices to make continuous improvement work.

In a second school of thought, traditional EA work establishes a business process baseline. Once there's a baseline, the continuous improvement process helps keep it aligned with business efficiency and opportunity signals. With this approach, EA doesn't play a strong ongoing role. If an external team was contracted to establish the enterprise architecture, that work simply ends and a continuous improvement process takes over. If internal EA created the process models, those resources move on to other projects.

Some experts see continuous improvement as a means to create a business process link to software development and selection, even without EA modeling. However, this approach forces the continuous improvement process to absorb much of the EA functions without the context from a model. For simple businesses, this construct might work. For enterprises, it's a questionable approach, at best.

Get started with continuous improvement

In addition to the Deming and Kaizen models that frame the overall implementation, continuous improvement in action has a number of competing approaches to implement it.

Software designed for continuous improvement usually supports one or more of these techniques:

• A3, for problem solving;
• a gemba walk, an informal interpersonal collaboration approach;
• Kanban, for process visualization; and
• the 5 Whys, a thinking exercise.

The competing models can complicate continuous improvement efforts. The Deming Plan-Do-Check-Act approach or the Kaizen Identify-Plan-Execute-Review model must connect to specific activities that managers can organize and execute. There are five such activities needed to reap continuous improvement benefits:

1. Establish a culture that encourages suggestions for improvement, both from staff, as well as from partners and customers.
2. Provide a means to collect and process these suggestions in an organized way, and detail the benefit that the improvement is expected to produce.
3. Use a collaborative framework that involves both technical personnel and operations or outside sources to process the suggestions. Create communities of practice and centers of excellence. Use appropriate tools to facilitate collaboration.
4. Use the results of collaboration to feed projects to operations teams, for manual processes, or to drive CI/CD activity, where software-assisted operations areas are targeted. Push these results through the EA model, if one exists.
5. Continue to collaborate through implementation and adoption to tune the changes and validate their outcomes.

Pros and cons of continuous improvement

The benefit of continuous improvement is obvious: You optimize operations and software based on real-world input from those who use it or are affected by it. When used as intended -- and linked to both EA and CI/CD -- continuous improvement is an effective way to close the loop on dynamic, Agile process management.

However, continuous improvement feels like an abstract concept. This complaint is most common among organizations that attempt it without a preexisting EA framework. EA, too, is abstract, while software design is not, which makes it difficult to coordinate the practices and behaviors of the two approaches. Continuous improvement requires the app-dev team to adapt in the same manner it would with EA; if that's the first experience it has with the translation, it's likely to be an unhappy one -- one that requires considerable effort and, perhaps, outside help.

Another, more technical, issue arises when enterprises implement a continuous improvement process. The improvement actions must link to CI/CD if they impact or rely on software. However, CI/CD pipelines can support multiple code releases per week, or even per day. Continuous improvement is a cooperative and manual process that typically takes place over multiple weeks. It might not feed into CI/CD often enough to meet goals. To address this problem, feed the continuous improvement activity into a change queue in CI/CD, where other, more traditional IT initiatives, such as software change management, also feed their outcomes. Then, merge the two feeds and use the information to help you define new projects.

Ultimately, the continuous improvement process demands a linkage from business operations to software development. If you can adhere to this basic truth, you can achieve the benefits of continuous improvement.