Research at AIIT

Dialog with an Uncertain Future / Excerp (Irregular updates)

The 25th Installment“Invisibility and Architecture”

by Yukio Namba,
Professor, Masters Program of Information Systems Architecture

When you go to the bank or post office, the waiting area is often crowded with customers, and it can take thirty or forty minutes until you are served. Customers receive a numbered ticket and compare the number of open windows with the number of people waiting, and if time permits, they reluctantly decide to wait. In the case of sales of popular gaming software and equipment, the quantity of products to be sold may be limited due to difficulty meeting demand during initial production. In this case, customers who are eager to purchase the product are willing to wait in line all night long.

In the case of e-Business, things are completely different. When a limited number of popular products are released on the Internet, customers rush to access the site as soon as sales commence. As the load on the sales system increases rapidly and almost reaches capacity, processing efficiency may reduce or the servers may go down, depending on the circumstances. In this case, if the system operator doesn’t respond to the situation properly, it will be criticized by the customers.

Before joining this university, I worked for an online securities firm. With securities firms, when orders are placed in person or by telephone, in principle, people serve the customers so they will not be subject to as much criticism, even if it takes some time to complete the orders. In the case of online transactions, however, the situation is completely different. Problems logging in are completely unacceptable. Even if the order processing is only delayed by a few dozen seconds, the operators may be rebuked by the customers.

Usually, the invisibility of the object is used to explain these kinds of situations. What exists in the real world is visible: you can see how many people are waiting at a glance. The facilities and mechanisms in the virtual world on the other side of the Internet are invisible and inconceivable, however. Even if you visit the data center, you will only see the servers, network equipment, wiring and so on, but you cannot know the extent of the processing capacity unless you are an expert, let alone how it is working inside. This represents the characteristics of logical artificial products such as information systems.

If things are visible, people understand the situation intuitively. If things are invisible, however, they cannot grasp the situation using their senses. In particular, they cannot see how many people are accessing the site instantaneously via the Internet. As a result, customers feel that they are the only one accessing it in the virtual world. If you take advantage of this feature, the customers and the service provider can develop one-on-one relationships. One-on-one marketing targeting individual customers should be effective. On the other hand, if they are not satisfied with the service, they will feel that they are the only one to have received poor service.

Dr. Tsuruho, former President of SEC, IPA, presented the opposite view in lectures. He said, “If the physical architecture is hidden by walls, you can’t see what it is like inside. In the case of software, however, you can understand everything by simply looking at the source code.” It is true that you cannot see the structure of the internal steel frameworks and reinforced concrete of those parts of a building that are covered with concrete. If you want to see them, you need to break them. For software, in principle, if you look at the source code, you can understand how the data is processed. Even if there is no source code, it is possible to analyze it by using the reverse engineering method.

Nevertheless, there is no end to faults and bugs caused by software problems that are supposed to be visible. News articles continue to report system issues, including the recent news about the problem caused by the software in hybrid cars. What’s the problem? Many reasons have been identified: insufficient tests, the inadequate skills of the people who make them, poor design and so on.

The essence of these problems is the fact that the bigger the scale is, the more complicated the system becomes. It means that the object is too large for individual people to recognize it. In other words, the system becomes so large that they can see the object to a degree, but cannot comprehend the entire system, so it is beyond the limits of human perception. What should we do? Architecture holds the key to the solution.

Simply put, architecture is a design idea for dividing an object into meaningful components and integrating them to suit the purpose. If you intend to build large network systems, it is impossible to do so alone, so the systems need to be divided into several elements. If the individual elements are closely related, a problem with a single element will affect the other elements. It is therefore crucial to determine what highly individual components they can be divided into, and then how these elements can be integrated to suit the purpose.

Architecture and architecting, which is the process of creating architecture, are essential for visualizing complicated objects. It is common, however, that network systems, which were initially designed and built according to meticulous architecture, are changed repeatedly in a haphazard manner as time passes and they respond to requests for changes. As a result, they often end up as a so-called spaghetti structure, in which the individual elements are intricately entangled. This is also one of the main reasons why information systems cannot respond quickly to business demand.

To get information systems to meet business needs in a timely manner and contribute as a business enabler, their own structures need to be designed to adapt to change. This means designing the architecture appropriately. To this end, it is useful to design the architecture of corporate information systems, which are an organic group of individual systems, from the perspective of the entire company, and to consider the architecture of the individual systems within it.

Back to index page