Vendor Management Tips: The Details

February 21, 2005 (Computerworld) -- The devil's in the details when it comes to vendor management. Don't forget a step with these tips from IT managers on planning, pricing and contracts.

Start with a pilot to minimize initial spend. See how flexible the vendor can be. -- Rod Traver, senior vice president of technology, Robert E. Nolan Co., Weatogue, Conn.

Develop and follow a strategic IT plan before making any long-term decisions on hardware, software, maintenance and/or consulting services. Decisions such as lease or buy, in-house or outsourced, single- or multiyear agreements, upgrade or replace can only be properly assessed in the context of a strategic plan. -- Timothy C. O'Rourke, vice president for computer and information services, University of Miami, Coral Gables, Fla.

On larger purchases we frequently quote several vendors, as well as make the vendor aware they are not the only bidder. This assures us that we are getting the best deal possible. If a vendor is not in line with the other quotes, we bring it to their attention in case they misquoted and allow a requote. -- Rick Peltz, senior vice president, Marcus & Millichap, Encino, Calif.

Keep them in the loop. Make sure the vendor knows you are also looking at strong, legitimate competition. -- Rod Traver

Network with peers in your industry to understand pricing models and trends. Develop and propose your own pricing models (for example, "per business process" or "volume-based" versus "per seat" or "per server") that fit your situation. Another angle, while only suitable for certain types of systems, is value-based pricing -- paying only for the benefits achieved. Let the vendor react to those proposals. -- Rod Traver

Don't let the vendor manage the project. Make sure that someone in your organization is responsible and accountable for organizing the project and delivering results within time, scope and budget. -- Don Eginton, deputy CIO, city of Phoenix

Prohibit your technical staff from negotiating with a vendor. Your organization's technical staff is vital in providing technical guidance through the negotiation process, but your negotiating team is better able to interact with the vendor's sales representative. Also, technical staff are normally concerned with things other than finances. -- Timothy C. O'Rourke

Hire a good project manager. A professionally certified and experienced project manager will be accountable to your organization, possess the right skills and be familiar with the tools and techniques for successful vendor negotiation. -- Don Eginton

Consider establishing a biyearly IT budget review process with vendors, and advise your vendors of the review dates in advance. Ask them to provide you with two or three cost optimization proposals (I don't like "cost savings" -- use "cost optimization" instead). Those should convince you and your business that future cooperation with the vendor will fit within your financial model and budget. Ask key vendors to attend a short meeting and present this strategy to you and another member of the senior staff. Usually, vendors will be able to work out some good deals to impress you, on every meeting. Good proposals received from some vendors may be implemented for others. -- Andrew Guzowski, IT manager of information, Australian Council for Educational Research, Camberwell

Think big. Put together the biggest deal you can from the outset. The bigger the deal, the more attention you will get from the most qualified people on the vendor's staff. You can always scale back the deal depending on how well their terms fit your needs, but you will have the advantage of "volume" pricing from the start. -- Pat Smith, corporate vice president of MIS, Stiefel Laboratories Inc., Coral Gables, Fla.

Setup is key. Site preparation and doing an orientation (making sure everyone has the hardware/software needed and knows how to use it) and co-locating vendors with your own staff is imperative. Having vendors in close proximity to your staff (technical and users) working on a project is very beneficial and can help assure that both sides have the advantage and opportunity to develop a faster and usually better orientation (to how we do our business) and working relationship. Sometimes the informal communications this offers is more important than the formal reports and briefings. It also affords a nonthreatening way to monitor vendors and how hard they are working and it allows you to know who their real stars are. -- Mark Mazza, IT department, state of Wisconsin

Timing is everything. It's amazing how aggressive public companies become at the end of the quarter. Use that to your advantage. -- Stephen R. Smith, Entity CIO, Hospital of the University of Pennsylvania, chief technology officer, University of Pennsylvania Health System, Philadelphia

Balance the assignments. On large complex projects you need to make sure there is a conscious effort to balance the work assignments (long/short, good/bad, hard/easy) between the assigned staff (vendor and our business and technical staff) so that everyone is given a balanced and varied workload. Partnering with vendor staff can be a great learning experience but if one group feels they are consistently given the toughest assignments you run the risk of burning people out and increasing your absenteeism and turnover to say nothing of generating bad blood between your staff and the vendor. -- Mark Mazza

Try EAI. In tackling legacy application conversions, look at enterprise application integration (EAI) tools as a possible solution, especially versions of the Enterprise Service Bus technology. Though originally intended as app-to-app connectivity tools, many EAI tools work as well for intra-app processes. By implementing EAI and Web services linking the legacy application to new modular development, you can offload bite-sized programming rewrites a module at a time, gradually turning off legacy functionality. You control the pace of conversion, avoiding typical all-or-nothing conversion nightmares and preventing vendors from painting you into corners too early in development. -- Bob Jackson, senior vice president, deputy director of systems and technology, Sedgwick Claims Management Services Inc., Memphis

Do your homework. Take the time to read the book Getting to Yes, then agree on operating principles or pre-existing standards to base negotiations around with the vendor. -- Geordie Conyngham, CIO, Cerebos, Seven Hills, Australia

Have a starting point. Get to an agreed price (the first quote is always a "starting point") then agree to negotiate. This appears to be a standard Asian negotiating technique. -- Geordie Conyngham

Concrete Contracts
Make sure they stay on. It's important that you get the best qualified vendor staff bid to do your project, but it's even more important that you keep them for as long as they are needed. Many vendors bid their best personnel only to roll them off a project as soon as possible and rebid them on another upcoming project. Incorporate penalties that protect you from this practice and make sure you identify the key personnel that have to remain on your project unless you agree to release them. -- Mark Mazza

Make sure your vendor contract includes payment after services are rendered and accepted. If possible, leave at least 20% for payment after the last phase of the project. -- Don Eginton

Separate out the specifications and procurement process from the implementation process. Ideally, separate vendors should assist in developing specifications and in implementing the solution. -- Don Eginton

Check renewal statements. When a contract contains an autorenewal provision, send a letter immediately after signing that terminates the contract at the end of the current term, adding a statement about discussing a renewal prior to the end of the current term. This strategy prevents a forced continuation should you forget to give timely notice later and it provides a better negotiating position at renewal time. -- David Lewis, CIO, Deseret Mutual Insurance Co., Salt Lake City

Include usage rates. When writing a contract with baseline price, credit for nonusage and overage for excess usage, work with multiple business scenarios to model and see what rates for credit and excess usage will result in optimal contract. -- Shelly R. Selvaraj, ON Semiconductor, Phoenix

On-time delivery. Based on the project completion success experience (on-time delivery), write a longer-term contract to get lower cost and negotiate hard on early termination. -- Shelly R. Selvaraj

Watch the line items. When vendors quote "project management" as a line item for small professional services projects done on your site, don't pay them. And don't let them mark back up the professional services fees after the quote. Remind them at the hourly rate you are paying for professionals, any back-office "project management" from vendors should already be embedded in professional fees. -- Bob Jackson

Legal Eagles
Contract renewal tips. Make sure you have at least a 90-day window prior to contract renewal to use exploring alternatives, competitors and pricing. This allows you to negotiate from an informed position. The volume of sales calls and e-mails requires you to focus on only those solutions that appear on your advance planning goals and business requirements. Reading trade publications and analyst reports helps focus your attention to the leaders in the space. I depend very much on peer-to-peer feedback to weed out hype and identify reputable vendors. This includes attending local IT gatherings and networking opportunities. One unique resource is to develop a good relationship with professional technology salespeople. They tend to move often and choose vendors whose solutions are superior. This provides me with a higher level of trust when I'm dealing with someone with whom I've had a positive history of purchases and deployments. -- David J. Graham, senior director of IT, Vignette Corp., Austin

Get legal sign-off. Be sure to include your purchasing and legal functions in the review of any agreements and ask them to review product master agreements, hosting agreements, master services agreements and statements of work for conflicting terms and conditions, maintenance provisions and vendor audit provisions. -- Jeff Gott, director of corporate business systems, Abbott Laboratories, Abbott Park, Ill.

Everything in writing. Remember the mantra that "If it's not in the contract, it's not part of the deal." Don't rely on verbal promises. -- Dave Nagy, senior director of technical services information technology, Abercrombie & Fitch Co., New Albany, Ohio

Look at contract terms early. Salespeople will promise you the world. Get a contract early in the negotiation process and make sure it says the same thing your salesperson promised you. During the actual contract negotiation process, read each version carefully to make sure that your terms were not changed in successive versions during the negotiation. -- Pat Smith

Use the advice of good counsel. A contract is not only about how to get a project or service started but also about how to handle a divorce if relations should deteriorate and require either party to leave the deal. -- Dave Nagy


Reference:
Computer World. February 21, 2005. Retrieved on May 27, 2009 from http://www.computerworld.com/action/article.do?command=viewArticleTOC&specialReportId=761&articleId=99817

Vendor Management Tips: Building Relationships

Computerworld - These IT managers offer advice for driving the best deal with vendors while ensuring a mutually successful relationship.

Don't be afraid to share your priorities with a vendor. If the vendor can help, they will find a way to provide the best solution. If they can't help, they know they are not part of the priorities at the time. Let them know you will continue to share with them what you need and how they may play a role down the road. -- M. Lewis Temares, dean of the College of Engineering and vice president for IT, University of Miami, Coral Gables, Fla.

Create a competitive environment (at least in the eyes of the vendor) by seeking credible alternatives. Vendors that know they have secured your business are better able to seize control of the negotiations. Be wary of "partnerships." They are vendor's way of making sure you are going to use them. -- Timothy C. O'Rourke, vice president for computer and information services, University of Miami, Coral Gables, Fla.

Use vendors to help you build a business case or persuade reluctant members of your team. Vendors often have white papers and ROI analyses that can help you build a business case and are very willing to help persuade your team. Using them to help you build support also helps them understand your business and refine their proposal so it better meets your needs. In the best cases, you become partners where success makes both parties look good. -- Pat Smith, corporate vice president, MIS, Stiefel Laboratories Inc., Coral Gables, Fla.

Treat your potential partners and partners as such -- not as vendors. There is a real need to drive contract terms and legal conditions, but in the end, no contract in the world will adequately cover your long-term goals and expectations. Build a solid, true collaborative partnership with your vendors. It will pay off in the long run. When things go bad, and they most certainly will, who would you rather have at the table? A vendor or a partner? -- Rick Hamilton, director, service delivery, Cisco Systems Inc.


Find a way to build a relationship. Price isn't the only aspect of the relationship. Find creative ways to go beyond the transaction. At the university, we involve vendors with the students via executive speaking events, scholarships, internships and recruitment. Further, the faculty seek sponsored research with the vendor. We have a person who works to manage all aspects of these relationships so dealing with the University of Miami is pleasant and easy to achieve. -- M. Lewis Temares

Ask for ongoing responsibility. To be a partner, both parties must act like partners, which means helping each other beyond the cash exchange. Will the vendor continue to help you succeed after the sale? How and where have they done this before? What can you do to help them be successful beyond just buying their products? If they cannot think of ways for you to help them, then the only value they will get is money, and this means you will spend more for their products or services. -- I.H. Tyler, Quaker Chemicals Corp., Conshohocken, Pa.

Always get competitive bids. From the outset, be clear that they have to put their best price on the table. No one will get a second chance to rebid. And never, ever give one vendor's bid to another to beat. -- Shahri Moin, Oscient Pharmaceuticals Corp., Waltham, Mass.

Be respectful to your vendors. If you have no intention of giving them your business, don't ask them to participate. -- Shahri Moin

Look to the long term. If the vendor staff at the table are here to stay, ensure that it is a win-win opportunity. If not, go for the max for your company. If they are here to stay, you'll just pay later for any aggressive short-term gains. -- Stephen R. Smith, entity CIO, Hospital of the University of Pennsylvania/chief technology officer, University of Pennsylvania Health Systems, Philadelphia

Negotiate with the top two. After evaluating a number of vendors, conduct contract negotiations with the final two, not just the final one. That enhances competition, and you may discover a deal-breaker with the top choice. -- David Lewis, CIO, Deseret Mutual Insurance Co., Salt Lake City

See the other side. Make sure you understand the value at the other side of the table of each negotiation point. Sometimes you'll learn that something you find of minimal value is of major value to the vendor, and often this learning comes away from the negotiating table. -- Stephen R. Smith

Make it a win-win. I have found that when technology vendors commit to a result rather than a sale, their success is directly tied to my organization's success. This improves the chemistry of the relationship. It's not just about selling me the best software or hardware, or about a vendor getting the best margin. It's about two organizations getting into a collaborative and mutually beneficial business outcome. If both partners cannot get value from the investment (no matter the scale), then it is the wrong investment or partner. For example, if I am buying an upgrade of software from a vendor, I may ask the vendor to participate in my payback. Instead of paying the reseller upfront, I have metrics of my ROI which I share with them; they get paid when certain targets are met. -- Eric Goldfarb, CIO and executive vice president, PRG-Schultz, Atlanta

Offer to help. If you don't buy from the vendor, help them build relationships with the people you know that may face the issues their products address. This also builds the relationship without a transaction involved. When you go to negotiate with them, they will be more amenable because of all the help you have provided in the past. -- M. Lewis Temares

Dollars & Cents
Don't pay for features you won't use. Offer to pay for them later, if and when you grow into them. -- Rod Traver, senior vice president, technology, Robert E. Nolan Co., Weatogue, Conn.

Start by defining what the "best deal" means. There are business objectives associated with every technology-related acquisition. There are lots of techniques for driving toward lowest cost, but you need other approaches when the requirements involve tight time frames, continued support or total value. In most cases, metrics with contractual remedies should be included to be sure the goals are clear and measurable and that the deal was, in fact, the right one. -- Joseph A. Puglisi, group CIO, Emcor Group Inc., Norwalk, Conn.

Tie guarantees to money. Guarantees aren't worth anything unless there are monetary penalties. They must be spelled out in the contract. -- David Lewis

Focus on value, not price. Before a negotiation, determine what is of value to your firm -- for example, the successful implementation of the system, with users gaining 20% improvement in time reductions. Use this value analysis to drive the discussions with the vendor -- can they deliver this value and then align their price to this? -- I.H. Tyler

Demand proof of concept. If you are seeking value, then you need to see it firsthand. So make the vendor prove it can be done, hopefully by implementing something at your location with your people and data. Often this works with appliance-type systems or infrastructure. If the situation is for something more complex, then you must meet with users of the firm's products and really do due diligence to see if they are getting the values you seek. -- I.H. Tyler

Reference:
Computer World. February 22, 2005. Retrieved on May 27, 2009 from http://www.computerworld.com/action/article.do?command=viewArticleTOC&specialReportId=761&articleId=99816

Elevator Pitch 2

As I worked in IT firm and software design for more than 10 years, but computer technology is going beyond. A large number of new concepts are coming. New products are ubiquitous in our life and changed our life style, such like mobile technologies.

This course systematically introduces e-Commerce, technologies used in distributed applications and some business models used in Internet. It helps me to get in-depth knowledge about e-system and will guide me for further system design.

I was working in ERP system design. Although an ERP system is dedicate for one organization, but for most companies, especially for multi-national companies, ERP is not just a in-house software, it will connect to others via network or Internet, such suppliers, shipping lines, distributors even end customers. It raises a lot of security issues while building infrastructures and applications. Incorporating new technology into ERP system will improve both system efficiency and development efficiency; and save maintenance cost.

For example, data replication will be important sector while designing a distributed application, such like a B2B system, which is connecting multiple networks that located in different geographic regions. Different networks are interacted for data transmission all the time. Data replication will reduce the on-demand data transmission through the network from the other country. It will improve system performance. But data replication will raise an issue of data inconsistency. Hence, at system design phase, we have to investigate whether the technology is suitable for our business type.

That is all for Kwan’s elevator pitch 2.

Software Development Life Cycle (SDLC)

Summary: As in any other engineering discipline, software engineering also has some structured models for software development. This document will provide you with a generic overview about different software development methodologies adopted by contemporary software firms. Read on to know more about the Software Development Life Cycle (SDLC) in detail. Curtain Raiser Like any other set of engineering products, software products are also oriented towards the customer. It is either market driven or it drives the market. Customer Satisfaction was the buzzword of the 80's. Customer Delight is today's buzzword and Customer Ecstasy is the buzzword of the new millennium. Products that are not customer or user friendly have no place in the market although they are engineered using the best technology. The interface of the product is as crucial as the internal technology of the product. Market Research A market study is made to identify a potential customer's need. This process is also known as market research. Here, the already existing need and the possible and potential needs that are available in a segment of the society are studied carefully. The market study is done based on a lot of assumptions. Assumptions are the crucial factors in the development or inception of a product's development. Unrealistic assumptions can cause a nosedive in the entire venture. Though assumptions are abstract, there should be a move to develop tangible assumptions to come up with a successful product. Research and Development Once the Market Research is carried out, the customer's need is given to the Research & Development division (R&D) to conceptualize a cost-effective system that could potentially solve the customer's needs in a manner that is better than the one adopted by the competitors at present. Once the conceptual system is developed and tested in a hypothetical environment, the development team takes control of it. The development team adopts one of the software development methodologies that is given below, develops the proposed system, and gives it to the customer. The Sales & Marketing division starts selling the software to the available customers and simultaneously works to develop a niche segment that could potentially buy the software. In addition, the division also passes the feedback from the customers to the developers and the R&D division to make possible value additions to the product. While developing a software, the company outsources the non-core activities to other companies who specialize in those activities. This accelerates the software development process largely. Some companies work on tie-ups to bring out a highly matured product in a short period. Popular Software Development Models The following are some basic popular models that are adopted by many software development firms A. System Development Life Cycle (SDLC) Model B. Prototyping Model C. Rapid Application Development Model D. Component Assembly Model A. System Development Life Cycle (SDLC) Model This is also known as Classic Life Cycle Model (or) Linear Sequential Model (or) Waterfall Method. This model has the following activities. 1. System/Information Engineering and Modeling As software is always of a large system (or business), work begins by establishing the requirements for all system elements and then allocating some subset of these requirements to software. This system view is essential when the software must interface with other elements such as hardware, people and other resources. System is the basic and very critical requirement for the existence of software in any entity. So if the system is not in place, the system should be engineered and put in place. In some cases, to extract the maximum output, the system should be re-engineered and spruced up. Once the ideal system is engineered or tuned, the development team studies the software requirement for the system. 2. Software Requirement Analysis This process is also known as feasibility study. In this phase, the development team visits the customer and studies their system. They investigate the need for possible software automation in the given system. By the end of the feasibility study, the team furnishes a document that holds the different specific recommendations for the candidate system. It also includes the personnel assignments, costs, project schedule, target dates etc.... The requirement gathering process is intensified and focussed specially on software. To understand the nature of the program(s) to be built, the system engineer or "Analyst" must understand the information domain for the software, as well as required function, behavior, performance and interfacing. The essential purpose of this phase is to find the need and to define the problem that needs to be solved . 3. System Analysis and Design In this phase, the software development process, the software's overall structure and its nuances are defined. In terms of the client/server technology, the number of tiers needed for the package architecture, the database design, the data structure design etc... are all defined in this phase. A software development model is thus created. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase. The logical system of the product is developed in this phase. 4. Code Generation The design must be translated into a machine-readable form. The code generation step performs this task. If the design is performed in a detailed manner, code generation can be accomplished without much complication. Programming tools like compilers, interpreters, debuggers etc... are used to generate the code. Different high level programming languages like C, C++, Pascal, Java are used for coding. With respect to the type of application, the right programming language is chosen. 5. Testing Once the code is generated, the software program testing begins. Different testing methodologies are available to unravel the bugs that were committed during the previous phases. Different testing tools and methodologies are already available. Some companies build their own testing tools that are tailor made for their own development operations. 6. Maintenance The software will definitely undergo change once it is delivered to the customer. There can be many reasons for this change to occur. Change could happen because of some unexpected input values into the system. In addition, the changes in the system could directly affect the software operations. The software should be developed to accommodate changes that could happen during the post implementation period. B. Prototyping Model This is a cyclic version of the linear model. In this model, once the requirement analysis is done and the design for a prototype is made, the development process gets started. Once the prototype is created, it is given to the customer for evaluation. The customer tests the package and gives his/her feed back to the developer who refines the product according to the customer's exact expectation. After a finite number of iterations, the final software package is given to the customer. In this methodology, the software is evolved as a result of periodic shuttling of information between the customer and developer. This is the most popular development model in the contemporary IT industry. Most of the successful software products have been developed using this model - as it is very difficult (even for a whiz kid!) to comprehend all the requirements of a customer in one shot. There are many variations of this model skewed with respect to the project management styles of the companies. New versions of a software product evolve as a result of prototyping. C. Rapid Application Development (RAD) Model The RAD modelis a linear sequential software development process that emphasizes an extremely short development cycle. The RAD model is a "high speed" adaptation of the linear sequential model in which rapid development is achieved by using a component-based construction approach. Used primarily for information systems applications, the RAD approach encompasses the following phases: 1. Business modeling The information flow among business functions is modeled in a way that answers the following questions: What information drives the business process? What information is generated? Who generates it? Where does the information go? Who processes it? 2. Data modeling The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristic (called attributes) of each object is identified and the relationships between these objects are defined. 3. Process modeling The data objects defined in the data-modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing the descriptions are created for adding, modifying, deleting, or retrieving a data object. 4. Application generation The RAD model assumes the use of the RAD tools like VB, VC++, Delphi etc... rather than creating software using conventional third generation programming languages. The RAD model works to reuse existing program components (when possible) or create reusable components (when necessary). In all cases, automated tools are used to facilitate construction of the software. 5. Testing and turnover Since the RAD process emphasizes reuse, many of the program components have already been tested. This minimizes the testing and development time. D. Component Assembly Model Object technologies provide the technical framework for a component-based process model for software engineering. The object oriented paradigm emphasizes the creation of classes that encapsulate both data and the algorithm that are used to manipulate the data. If properly designed and implemented, object oriented classes are reusable across different applicationsand computer based system architectures. Component Assembly Model leads to software reusability. The integration/assembly of the already existing software components accelerate the development process. Nowadays many component libraries are available on the Internet. If the right components are chosen, the integration aspect is made much simpler. Conclusion All these different software development models have their own advantages and disadvantages. Nevertheless, in the contemporary commercial software evelopment world, the fusion of all these methodologies is incorporated. Timing is very crucial in software development. If a delay happens in the development phase, the market could be taken over by the competitor. Also if a 'bug' filled product is launched in a short period of time (quicker than the competitors), it may affect the reputation of the company. So, there should be a tradeoff between the development time and the quality of the product. Customers don't expect a bug free product but they expect a user-friendly product. That results in Customer Ecstasy!

Reference:
Stylus Systems Pvt. Ltd. 2008. Retrieved on May 26, 2009 from http://www.stylusinc.com/Common/Concerns/SoftwareDevtPhilosophy.php

Workshop 8: Ruby on Rails Workshops Report and Evaluation

Please answer each question in this evaluation section. In your answer, please consider content/topics presented and the technologies and teaching strategies used during the Ruby on Rails Workshops. Results will be collated and used to modify the workshop series.

1. List what you consider to be the three strengths of Ruby on Rails workshop series

I consider the 3 strengths to be:

1. The package size is quite small. InstantRail already includes the web server and programming tools. And it is easy to use.
   
2. Learning materials are good and they are helpful, especially for beginners of web development.
   
3. Using Blog and Wiki helps to practise more of Web2.0
   

2. List what you consider to be the three weaknesses of Ruby on Rails workshop series:

I consider the 3 weaknesses to be:

1. It is time consuming if I tried to explore more of RoR for a particular problem
   
2. It it a little bit late for distributing the workshop 6, 7 & 8, just less than 2 weeks before original deadline.
   
3. Software "Aptana Studio" seems not helpful for RoR development
   

3. List what aspects of Ruby on Rails workshop series that you found to be most difficult.

Most difficult aspects are:

1. To manage controllers and actions between different views
   
2. Not easy to identify the problem for a beginner
   
3. To manage version control, deployment

4. List what improvements could be made to the Ruby on Rails workshop series:

Improvements could be made:

1. Make workshops more consistent. I mean a table "Passengers", the table definition are different in different workshops. It causes a little bit confusing
   
2. Consolidate similar contents and reduce number of workshops. Hence, we may have more time for each workshop.
3. For Hong Kong students, it might be better that form groups with managers and developers to discuss face to face to design the system and come out a solution by using RoR
   

Free response and reflective questions:

5. Reflect on your experiences with the other Web framework used in this subject: Was it effective? How can it be improved? Should other Web frameworks be used as well or instead of Ruby on Rails?

I didn't work in web system design in the past. But according my colleagues' experience, RoR should be compact and efficient. RoR already include web server software and development tool, and it reduces quite a lot of work. To choose which framework to use depends on the resources and cost of the company.

6. Did the Developer’s or IT managers Team that you joined after workshop 4 have a preference towards using other tools to facilitate collaboration? Comment on the differences between these use of the sub-forum or Interact wiki tools from your experiences in this subject.

Seems not many classmates participated the discussion or information sharing in focus group blog. I believe it might caused by limited time of assignments.

My opinion is sub-forum is much better for discussion, question and answer intercommunication. Wiki is a good thing, but I feel it is more suitable for information sharing. Everyone can contribute to a particular topic. Just like Wikipedia, I found a lot information there. Compare with the other website, Wikipedia provides much more comprehensive information.

7. Further comments to add?

By working on exercises and workshops, I feel there are many concepts, technologies to learn. It is helpful for me to get knowledge of e-systems infrastructure. Using blog and wiki to complete our assignment is a great idea. It helps us to experience, understand and practise web2.0 technologies.

In fact, I would like to participate both manager and development roles. But there were too much difficulties on RoR development, because I am new to web development. I spent a lot of time on finding solution for particular problem.

Furthermore, both exercises and workshops are time consuming that I have to search and read a lot of materials. Although I enjoy learning, but if possible, reduce our workload will let me enjoy my life as well.

At last, I appreciate the lecturer and Hong Kong tutor's efforts of providing instructions, comments and solutions.

Workshop 7: End of the Line: production site migration and maintenance

Developers conclude their work with the OTBS and look at the options for deployment of the site. Examine the various platforms/software tools used for deployment such as UNIX environment suggested in the Discussion Notes, Mongrel or Mongrel cluster, Nginx, Subversion or Capistrano (during development stage), JRuby in the Java environment.
Which way?

The choice is up to you as this workshop present just one option and you may like to use another, such as deploying the OTBS in a .NET or J2EE environment

From Workshop 1 to 6, I got basic knowledge of web development via working on RoR, such like MVC design pattern, CoC, DRY techniques. It is enjoyable to learn all of these things. While constructing a web page of RoR, I was trying to imagine that how a pupular website works. RoR is a simple but useful tool. If possible, in the future, I would like to develop a website by using RoR.

As I am a beginner of RoR, just started learning it when this course started. I am also beginner of web development. Thus I am not sure which deployment platform/tool is better. In computer science, we can't say which one is better than others, because it will be trade off between advantages and disadvantages.

According my past experience, UNIX is much more stable. But it needs costly hardware. Therefore, LINUX is a good choice. Wikipedia (n.d.) depicts that Mongrel is capable of serving Ruby on Rails powered sites without requiring any other web servers, though as a single-threaded application this configuration is unsuitable for all but light loads. However, it is faster and more stable than WEBrick, and easier to set up than Apache.

On the page of "Ruby on Rails: Deploy" (RubyonRails.org, n.d.) mentioned "Capistrano" that automates deployment. According to Capistrano homepage (capify.org, n.d.) that Capistrano is

• Great for automating tasks via SSH on remote servers like software installation, application deployment, configuration management, ad hoc server monitoring and more.
• Ideal for system administrators, whether professional or incidental.
• Easy to customise. Configuration files use the Ruby programming language syntax, but you don’t need to know Ruby to do most things with Capistrano.
• Easy to extend. Capistrano is written in the Ruby programming language, and may be extended easily by writing additional Ruby modules.

Zygmuntowicz et al (2008) gives a deployment map for RoR applications.

Can you get the OTBS Running in production mode as a minimal production server?

Apologize that I am afraid that I am not able to put the OTBS to production mode now. Firstly, I need more time to design a simple but complete system flow, database tables, construct web pages and testing. Secondly, I am using a laptop at home, there might be a little difficult that open my network to public.

According to Hartl and Prochazka (2008), they outline one possible deployment solution to deploy a Rails application.

• Linux/Apache/Mongrel for deployment
• Caching mod_proxy_balance and shared nothing and for scaling
• Subversion or darcs for version control
• Capistrano for automated deployment and rollback

Reference:
RubyonRails.org. n.d. Deploying Ruby on Rails is easy. Retrieved on May 24, 2009 from http://rubyonrails.org/deploy
Wikipedia. n.d.. Mongrel (web server). Retrieved on May 24, 2009 from http://en.wikipedia.org/wiki/Mongrel_(web_server)
Capify.org. n.d. Capistrano. Retrieved on May 24, 2009 from http://www.capify.org/
Ezra Zygmuntowicz, Bruce Tate & Clinton Begin. 2008. Deploying Rails Applications. Retrieved on May 24, 2009 from http://media.pragprog.com/titles/fr_deploy/chap6.pdf
Hartl and Prochazka. 2008. Railsspace: building a social networking website with ruby on rails. Person Education, Inc.

Exercise 26.3b

Manage and Develop ERP systems

ERP (Enterprise Resource Planning) systems are used in almost any type of organization, whatever it is large or small. They integrate the data and processes of an organization into one system with the end goals of making information flow throughout a company more immediate and dynamic; increasing the usefulness and shelf life of information; eliminating redundancy and automating routine processes; and making information system components more flexible.

Usually ERP systems will have many components including hardware and software, in order to achieve integration, most ERP systems use a unified database to store data for various functions found throughout the organization.

Below picture shows software components of ERP systems.

(Kunj Solutions, n.d.)

To manage and develop an ERP system, we need to consider below issues:

• Identify what we have and what we need
  

  That means we must understand the existing business flow and information flow among departments thoroughly, and what new features are going to implement in the future. Then design a new flow throughout the organization.
  

• Integrate the existing applications with the new ERP development
  

Most ERP systems offer all standard business logic and flow in the software package. But the organization might have some legacy systems, which are designed specifically for the business, that to be retained. While implementing the ERP system, we have to reconfigure those legacy application in order to plug into the new applications.


• Many interfaces for ERP development
  

  Interfaces are the fastest way for passing business information between the new ERP system and the existing stand alone systems. Interface development will maintain the original data integration of the organization.
  

• Database consolidation
  

  One of the most important features of any ERP system is that it is built around a "super-database," or an integrated, all-inclusive data storage system that encompasses all of the organization's operational data. There will be thousands of database tables created in the "super-database". All these tables integrate all system-specific or department-specific data. This is a key step in mobilizing for ERP.
  

• Access control
  

  As all data are integrated into one database, it will raise the security issue, especially for HR data such like personal data, salary, and so forth. Therefore, access control will help us to grant the appropriate privileges to each staff.

• Data access beyond the organization
  

  Web services provide real-time data access between our organization with the business partners; the economy for distributed systems, and the convenience of web-based interfaces for systems both remote and in-house have made will make the need for flexible data access a core architectural component in the ERP development.

In ERP environment, we will be experts in the components populating the various architectural tiers, in the relationships between the myriad database tables, and in the links, sprocs, and triggers that make the systems dynamic.


Reference:
Tech-FAQ. n.d.. What is ERP? Retrieved on May 19, 2009 from Tech-FAQ website http://www.tech-faq.com/erp.shtml
Wikipedia. n.d.. Enterprise resource planning. etrieved on May 19, 2009 from Wikipedia website http://en.wikipedia.org/wiki/Enterprise_resource_planning
SystemDisc. n.d. ERP. Retrieved on May 19, 2009 from SystemDisc website
http://www.systemdisc.com/erp
Eric Williams. 2008. CRM. Retrieved on May 19, 2009 from TechTarget website http://searchcrm.techtarget.com/sDefinition/0,,sid11_gci213567,00.html
Shannon Kietzman. 2009. Retrieved on May 20, 2009 from WiseGeek website http://www.wisegeek.com/what-is-workflow-management.htm
e-Workflow. What is Workflow? Retrieved on May 20, 2009 from e-workflow website
http://www.e-workflow.org/
Kunj Solutions. n.d.. ERP Development. Retrieved on May 20, 2009 from Kunj Solution website http://www.kunjsolutions.com/SoftwareDevelopment/ERPDevelopment.aspx
Scott Robinson. n.d.. A Developer's Overview of ERP. Retrieved on May 20, 2009 from Developer.com website http://www.developer.com/design/article.php/10925_3446551_1