From Lego toys to ancient Lijiang city-three metaphors for understanding the concept of SOA

It has been a few years since I first heard of SOA. During this period, I have had various discussions with various people, and I am increasingly aware that this is not a concept that can be clearly defined, in the past, there were no words in the software industry that were likely to cause so many criticism and debate. I sometimes think that SOA really wants to talk about it in Zen, "saying it is nothing ". The most difficult one is to say such an abstract concept to people without a technical background. The only way to establish a concept is to use a metaphor. Among the dozens of metaphors I have heard about SOA, several of them have been recognized by more people. Those technical staff who want to share this concept with business personnel and managers should not take risks any more. Use these metaphors to give it a try.

 Lego toys-SOA as a design philosophy

This is the earliest metaphor for success. Traditional applications are like normal toys and cannot be disassembled or spliced. SOA-based applications are composed of smaller service components, just like Lego toys. Lego toys can be used to build different shapes. For example, LEGO toys can be used for different applications. The modules of Lego toys are based on standards and can be reused. The advantage of this metaphor is that it quickly creates a mental image for non-technical personnel. In a seminar, the organizer sent some Lego modules for the customers to make things on their own. As a result, the audience quickly realized that they are doing something similar to software development.

Some people may say that SOA is so complicated that it is too simple to use children's toys. At this moment, there is a chance to further explore it. It seems that Lego toys are so simple and there is nothing to go. This implies a design philosophy. The teams that design Lego toys are a group of design experts with doctors. One of the contradictions they must solve is how to couple standards with loose coupling, the functions and mechanics of the module are all solved during design and planning, leaving users with only fun. An interesting fact is that Lego toys, such a seemingly simple thing, have never been an imitator. Software engineers can spend ten minutes saying they know what SOA will be like when everyone sees Lego toys. However, when a person understands the design philosophy similar to Lego and SOA from the perspective of designers rather than players, they will find that the service objects of the two are actually people who do not need to care about technology, they all pay for technology. Is the engineer a player or a designer? As a player, the engineer seems to know a little more. As a designer, he has too many things to learn, just as he wants to become the designer of Lego toys.

 

TV and Computer-A standard-based structure

 It is much harder to repair a TV than a computer, although the computer is much more complicated than a TV. Because computers have a standard-based structure, bus structure, and plug-and-play contract standards, these buzzwords in the IT field shape the PC industry. SOA also has several standard reference structures, bus, and loose coupling. These concepts are exactly the same as those in the PC industry. The advantage of this metaphor is that computers are a more specific example. This example implies several technical rules. First, the analogy between things must be homogeneous. This is a logical premise of the metaphor. That is to say, in terms of the basic structure, the design concepts of the two are similar. Second, the things used for metaphor are the most popular and popular things. Third, you can give at least a few points to prove the similarities between the two.

City Planning-SOA implementation requires a gradual Mode

Technology always jumps, and application systems are always moderate. In this example, the application is compared to a common building, while the SOA implementation as an enterprise architecture is compared to a city. The evolution of the city must be gradual. This is a metaphor for the implementation of SOA as a journey. For example, traffic in Beijing is always difficult to solve the problem of congestion, several loop methods are actually equivalent to the EAI method, and the result is bus congestion. If many of Beijing's urban buildings are scattered into smaller communities, it is similar to reducing the granularity of applications. As in San Francisco, many places will not be blocked at least. however, this transformation requires a gradual implementation method. If you think about how much time the subway in Beijing spent dealing with underground pipelines for the Olympic Games, you will know how complicated the transformation of the enterprise application architecture is.

The positive example is the ancient city of Lijiang, which was planned eight hundred years ago and is still vibrant. Therefore, it is called "a living Ancient City ". A river is divided into different channels to flow through the entire Ancient City. Every city has a sound of water in front of it. water can be used for laundry and cooking. All the streets are arranged according to the meridian theory, all blocks serve the same infrastructure. The most interesting thing is that, as the Sifang Street in the market, automatic water washing facilities are used. The whole terrain is high in the East and West, and the Sifang Street is high in the middle and the edge is low. Therefore, when people use the baffle plate to accumulate water, water can automatically impact the street. This design is said to have one in Amsterdam, but I don't know that one earlier. We can say that the design of ancient Lijiang city is service-oriented, and water is their public service. They also use some rules to regulate the use of water. For example, in the past, the morning water was at the same time, and everyone could cook and wash clothes at some time in the afternoon. In SOA, we can see service contracts, control rules, and infrastructure optimization.