Print

Consider for a moment the chain of instructions typically generated in the development of a simple business application. Like for example a ‘Customer Relationship Management System’ to keep track of leads, sales, orders, and accounting etc.

Between the time the president says something like, “We’ve got to get a handle on our customers, and the sales/order process! Can our computers help?”(He’s a big picture guy.) and the computers process all the appropriate ones and zeros (because that’s all they understand) come several levels of complicated and inter-related sets of instructions. The bigger the organization and the bigger the task, the more important these intermediate levels of instruction become to the ultimate success of the project.

In the small organizations, the executive may be able to take a hands-on approach to the project because he may have the time, interest and intimate knowledge of the business processes below him to guide the project along the right path. And the programmer may have access to the executive and be involved with the ‘real- ‘real-world’ aspects of the business.

But as the organization and the project become more complex, there are likely to be several levels between the executive and the computer, all with competing aims, views, and ways of speaking, thinking, and communicating. The finance guys are interested in budgeting and the expected ROI for the project. The sales guys want instant turnaround and constant flow of information on the orders, satisfaction of both real and prospective customers. Manufacturing unit wants to schedule production easily and information on how to improve the product and lower the cost of manufacturing. Accounting Department wants control of accounts receivable and good credit information for all customers. The operations people want the project completed in the shortest possible time and with as little retraining of the clerical staff as possible. And IT wants a clear and unambiguous plan of attack and conformity with their own scheduling needs.

And they all speak different languages! The boss has no concept of file structure and no thought of database throughput speed. Finance seems to only care about ‘the numbers’. Sales, operations, manufacturing and accounting will each have several ‘amendments’ to the original design before the project is finished (which will add to the cost) because they have rethought their needs, have discovered another benefit, have been saddled with a new governmental regulation, or all of the above. . IT guys may have little understanding of the realities of the business and are hard-pressed to assimilate the new revisions under the initial cost structure.

Each and every one of these groups is correct in their expectations and has a right to demand that their requirements be addressed to their satisfaction. It’s also true that many of the mentioned goals are in conflict with the others, making a solution which makes everyone equally happy a difficult challenge.

What we do here, as much as anything else is translate! We are able to communicate the boss’s comments to the computer and have the computer spit back information that is useful to the business enterprise. This requires the ability to quickly understand the business requirement of the assignment and design cost-effective ways to gather and use information to fulfill those requirements. The ideal solution that we suggest is to employ UML.

Resources

This resource provides comprehensive information on UML.

This is insightful information on UML.