| About My Work | 1 | 2 | 3 | 4 | 5 | 6 |
Eventually, this role evolved to take me into the Framework group, where I continued my product management roles examining our strategies toward integration with other companies' application products, and our future evolution towards a "component-based development model". If this buzzword sounds over-the-top, you're not alone. But the idea is fairly simple, even if the reality is not, so let me explain a bit about that.
Today, Applications ships its entire suite of products as a single entity. So even if you only license one or two products (which is unlikely, given how many are usually used together), you still have to install all 100+ products. This is mainly done to ensure higher quality: because every product has dependencies on hundreds to thousands of objects from various other products, the chance of missing some if only those that are needed are installed is considerably great. By installing everything, you're always guaranteed to have what you need. However, this is difficult to manage when you want to upgrade: if you're using products from many different areas, but just want to upgrade products in one area, you're out of luck — you have to upgrade everything, or nothing at all.
The direction is to deliver the suite as a set of "components". The term "components" has a special meaning in the software industry: it refers to a large piece of software that is designed to easily and seamlessly "plug-in" to a network, and communicate with other components. You don't have to anything about how a component works to use it — you just drop it onto a machine and let it do its thing. Similarly, components don't need to know anything about each other: they just magically talk to each other, exchanging necessary information to carry tasks from one component to another. So in our case, we're trying to identify groupings of products that mostly work independently of the others, and repackage them as a single component. This would allow users to upgrade a single "component", while leaving the others mostly untouched. Furthermore, you could use components from our product suite with those from other companies' product suites, making it easier to use at least some of Oracle's products without having to give up huge investments you may have made in other areas of your business. (We'll take care of those areas later.)