“Why IBM i?” Architectural Foundations
I have recently had several opportunities to give a brief explanation of the architecture of IBM i -- to explain the key foundational elements and explain why these make IBM i significantly different from other operating systems. Today, I will share with you the notes I wrote for one of these sessions. When I present the “Why IBM i? A System Designed for Business” presentation, I often say I could talk for 30 minutes or more on one single chart -- the chart that lists these elements. I never get a chance to talk for that long, but here is the shorter version. I hope it helps you.
IBM i is very different from the other operating systems in the industry, and the differences are related to its unique architecture. From the birth of the AS/400, the goal of the operating system was to create a platform that would allow a business to be insulated from the complexity of IT technology. Our customers want to "run the business, not the computer." The five architectural elements below are not just marketing words -- they are built into millions of lines of operating system code -- and their purpose is to make IBM i stable, simple, secure and scalable.
DB2 for i & Single Level Store: We build intelligence and expertise into our handling of customer data. DB2 on IBM i is a part of the operating system, and it automates many functions that require human analysis and management on other operating systems. Single Level Store is a way of treating all storage attached to IBM i as if it is one huge set of memory. Working with DB2, our storage management spreads data across a customer's DASD in order to optimize data access. For these two reasons, customers rarely have to hire storage administrators or database administrators for their IBM i environments, and those professionals who are hired spend more time on analysis than on day-to-day management.
Object-Based Architecture: AS/400 was built understanding that security would be a key requirement of all businesses. Each object on IBM i has a set of well-defined functions, and it is architecturally impossible to treat an object in a way that violates its intended use. For example, two common methods of spreading viruses or “Trojan Horses” in other operating systems are to modify code in a compiled executable, or to rename an object so that a program looks like something that is not dangerous -- sending a program in an e-mail but making it appear to be a photo, for example. Neither of these two attacks can be done to software compiled as IBM i programs, because those operations are simply not allowed by the architecture.
Integration: We believe that the only software a typical customer really wants to deal with is the software that runs its business directly -- the applications that are developed by the customer or that they buy from our ISVs. For that reason, our operating system comes integrated with all of the necessary "middleware" a business application might need: Not only DB2, which I mentioned before, but also web servers, security services, user identity management and so on. These pieces of middleware must be added on top of other operating systems. We incorporate them into IBM i, and we ensure they fit into the architecture of the system, including the object-based architecture I mentioned, as well as the virtualization and TIMI I will describe next.
Work Management: The AS/400 was built assuming that a business would rather have one physical system that is capable of running all of the workloads it needs, rather than buying a new system for each workload. To support that idea, IBM i has a "subsystem" concept that allows an ERP application to sit next to a CRM application, which sits next to a web server and so on -- all of them sharing resources such as the database, but not colliding with one another. This is very different from typical competing operating systems, where it is architecturally difficult to run multiple workloads safely on one machine -- or one virtual machine -- and so the industry has had tremendous "sprawl" as customers of other platforms have had to buy a new system for each application or workload. Yes, today these other operating systems “solve” the problem their architectures created with virtualization. Subsystems are a virtualization technology that existed since the beginning of the operating system, and they allow an IBM i client to spend less on managing multiple environments.
Technology Independent Machine Interface: IBM i is split into two pieces, and the TIMI separates them. The TIMI also provides a layer of abstraction that does two important things. First, it allows programs that were compiled on older releases to run unchanged -- without even recompiling -- as IBM i changes technology beneath those applications. The operating system moved from a 48-bit CISC hardware architecture to today's Power architecture without the need for customers to recompile code. Second, the TIMI works together with some of the IBM i-specific capabilities built into POWER processors to keep system memory separate from user memory, protecting the operating system from intentional or unintentional interference. An interesting point though, is that all of the IBM i "device drivers" for I/O are beneath this TIMI. To protect the integrity of the operating system, and by extension the customer’s data, IBM i cannot have a "device driver" authored by another provider.
For those of you who made it to the end of this, thanks for reading. I suspect all of you now feel like you could develop the next extension to this extremely integrated operating system. No? Well, then perhaps you at least could explain some of its value to the next person who needs to hear it.
Twitter: #ibmi, @Steve_Will_IBMi