Beyond SOA: A new Enterprise application framework for dynamic business Applications (2)

Part Two: The practice of Dynamic Business application construction--The story of two adaptive systems

Productivity improvement is the basic component of the improvement of living standard. The experience of the United States shows that the strong growth in long-term productivity is the result of technological innovations accompanied by changes in organizational structure and corporate capital arrangements, as well as investment in human capital. But the determinants underpinning these productivity gains are a more fundamental factor: the will of society to make a major change in itself, and the confidence in technological progress and economic opportunity that comes with that progress will improve people's lives.

–roger W. Ferguson Jr. and William L. Wascher, Economic Society of the United States of America: Lessons from the Big Bang of the past, economics Outlook magazine, Spring 18 2004, Phase 2nd

"Once you start automating these [enterprise] processes, technology implementations account for about 10%, and the remaining 90% are change and process management"

–mark Evans,tesoro Petroleum CIO, Management automation, March 2004

The first part summarizes

In the first part of this article, we introduce an enterprise architecture for building new IT systems, which we call Dynamic Business Architecture (DBA). These DBAs are well suited to support businesses that have dynamic operations (a classification that includes the latest business). The first part also points out that the use case is the basic input to the current system architecture and design, and describes the constraints that depend on the requirements gathered through it to the current enterprise architecture approach. This new framework uses the Enterprise event model as a starting point and regards the enterprise as an adaptive system with a clear information architecture. Based on new adaptive systems and information theory, the framework captures both enterprise processes and business changes at the base level. Use cases are introduced only later in the design process as a requirement refinement method. This framework-first approach has been inspired by traditional engineering methodologies, but has been modified for adaptive systems such as enterprises.

Introduced

It's time to say goodbye to the manual workshop and add the right engineering technology to software engineering. This is the only way to build complex software applications, especially in the enterprise domain, into highly reliable, easy to change, and easy to debug public standards. Selecting and executing the correct system architecture is the most important factor in making this approach work. Our proposed solution makes it possible to standardize on only one system architecture (regardless of software applications) and avoid costly re architectures.

As mentioned in the first part of this article, there is a fundamental difference between architecting software applications and designing other engineering products. Because software is about information and information is the "carrier" of change, changes must be built into the information architecture at the most basic level. In addition, the ways in which business operations are changed and the way in which technical groups introduce changes to the system are completely different paths. They are both organizations that differ in their response to change and have different operations (one is business and one is technology). In the framework process, the two organizations can be treated as two different adaptive systems. This is why we chose the story of two adaptive systems as part of the second subtitle of this article.

In the process of designing enterprise application, two adaptive systems are involved.

The first part of this article mentions that the only way to successfully manage the complexity of a DBA is to use the architecture-leading methodology. Engineers have been using this methodology for centuries-but always designing a "static" architecture. Once the changes are applied, the system will most likely have to stop working before making any changes. For example, to change a product assembled by an assembly line, you must stop the assembly line first, then apply the change, and finally restart the assembly line.

Today, the software engineers who build IT systems for the business are likely to follow the same routine. When business changes suggest a need to modify the application, it is likely to trigger a costly upgrade. The developer must start a new business requirement from scratch, and the old design often suffers from a lot of reframing. This upgrade cycle may take several months. If an enterprise application is built by an external developer on its own schedule, the entire process may take longer and results may not reach business expectations. Mark Evans says that more than 90% of the effort is directly related to applying changes.

With the help of the new adaptive systems theory and their information architecture (see outsider Perspective), our proposed enterprise Application design solution introduces two complementary but unique frameworks. These two frameworks allow us to effectively handle and coordinate changes in business operations and technical community operations. For the design process, business operations and Technical group operations can be viewed as two distinct adaptive systems, each of which has its own needs.

Business operations can be represented by a common concept of the underlying dynamic business platform. According to adaptive system theory, there are 3 kinds of basic processes in any enterprise business function. The main process type supports normal operations, while the other two are responsible for introducing changes: internal decision making process management and other enterprise change decisions, and business environment change processes that address other external sources of customer decisions and changes. Therefore, our proposed Business process framework (basic dynamic business platform) is built around business operations or value loops, and it contains two types of changes that are handled by two different change management platforms. From the point of view of information processing, the systems that implement these operations can be compared to the "Information assembly line" built around the event model (see Part One). Business operations can be identified by a methodology similar to that derived from Toyota's Lean manufacturing Best Practices Value flow chart (value Stream Mapping) methodologies. As a result, the lifecycle/event model is the primary driver of system design and architecture, and unreliable use-case collections are no longer the primary input to the system architecture.

The technical operation has its own challenge and unique dynamic nature. The main goal of technical operations is to enable different teams to collaborate to the fullest extent in the process of introducing changes. The basic dynamic business application is an adaptive system with two kinds of processes: operation and operation Change. These two processes link technical support (operations) and technology development (operational change) to business users.

Figure 1. Building and maintaining the underlying business dynamic platform requires both a business process framework and a business system change management framework.