Skip to Content

If Yan can Cook… Yan Could Code… (SAP NWDI Part IV)

If Yan can Cook… Yan Could Code… (SAP NWDI Part IV) Part IV – Box it up and Deliver it Welcome to “If Yan can Cook… Yan Could Code… (SAP NWDI Part IV)”. If you would like to go back and start this series from the beginning please follow this link: If Yan can Cook… Yan Could Code… (SAP NWDI Part I). In the previous entry I talked about recipes, ingredients and Development Objects (DO’s). I would like to move forward now and talk about Development Components (DC’s) as well as their relationship to Software Components (SC’s). I look at DC’s as different parts of the larger order that is placed at a restaurant. For instance an order may come in from the Manager for a large Sausage Pizza, French Fries and a six pack of Beer. The entire order contains multiple pieces that may need different people or Chefs to fulfill the various parts. There is a Fry Chef that handles the French Fries order, a Pizza Chef that makes the Pizza and that guy with the headphones on that is responsible for the beverages in any given order. All of these Chefs are essentially developing different Development Components that make up the final order which is the Software Component. These Development Components are defined and built/coded by the chefs/developers to the guidelines of the initial order. The Chefs are essentially all making their own unit of build and deployment. In the end they also have to fit together and work with all of the Development Components that the other chefs are creating for the order also. These Development Components have some uniqueness about them. They are all mapped back to the Chefs Kitchen or Developer Studio/Eclipse projects. They are also mapped back to the Eclipse project types. The Chef/Developer can use the kitchen/Developer Studio to automatically create the projects for the DC’s that are available in the repository. The dependencies for the DC’s like libraries etc. are automatically referenced also. This is excellent from a multiple developer point of view because when everything is checked back into the system there will be compatibility and error checking done to make sure that the DC’s will work with the other reference objects, components etc. that already exist. Meanwhile… Back in the kitchen, all of the chefs have finished their various pieces to the order and it is time to bundle them up into one finished product. So if you think about it all, multiple DC’s will make up a single SC which is in all logical terms a unit of delivery. Each SC will be looked upon like each order at the pizza place; Unique. Therefore each SC will be a viewed as a new software release just as every new order called in is looked upon as a new request for development and/or product. This SC is made up of a specifically calculated number of Development Components. These Development Components were earlier defined by the person taking the initial restaurant order or in the coding environment by the Development manager or Team Lead of the development group. Once the order is completed it can be packaged up together to form the final piece. This is the Software Component that is now ready to be transported. The Manager takes the DC’s, checks them into the system and against the development request and makes sure that they are up to specs. Then they are bundled and placed in a staging area where they can be transported to their final destination. We can also loosely couple the idea of the Pizza delivery guy to the JAVA transport system that moves the finished SC’s from dev to staging to QA and eventually to production. Hopefully this is all this transport will need to be delivered is 30 minutes or less.
You must be Logged on to comment or reply to a post.