The master key, the catalyst, and the magic drug' for SMEs (small and medium enterprises) is information technology (IT), avers Vineet Bajpai in The Street to the Highway(www.jaicobooks.com) . For, behind the transformation of traditionally slow family businesses into value-creating modern outfits, French and Italian designers targeting Japanese customers without opening stores in Tokyo, global travellers booking a room in Agra without the help of a travel agent, mid-sized businesses hiring only one accounting professional instead of the usual three earlier, and people manufacturing mobile phone covers becoming millionaires, what Bajpai finds is one fundamental driver — IT.

Big vs small

In the author's view, IT has made as much an impact on SMEs as it has on larger enterprises. As examples, he mentions that while large companies use ERP the smaller companies have seamlessly moved to user-friendly accounting software; and how the big enterprises have connected global offices through virtual private networks while small companies use the Internet to reach out to millions of international buyers. And even as the biggies invest in enormous CRM (customer relationship management) applications and set up server farms, the micro businesses are using simple software to create customer profile databases, and the young entrepreneur of today carries a laptop!

So, the one clear message is that technology is not, and should not, be looked upon as the playground of some techno-savvy modern professionals, but as an inevitable new force in our business dynamics. Bajpai urges the business beginners: “If you use it well it could prove to be the greatest step you ever took and give you return on investment that you never imagined. If you miss it, it could push you behind by several laps vis-à-vis your competitors.”

SANCTITI model

The book advocates a ‘simple assessment and navigation chart to initiate technology implementation', or the SANCTITI model, addressing the four pillars of the organisation's workflow, namely, sales and marketing, operations and internal processes, finance and accounts, and vital support functions in the form of human resources and administration.

For each of these, the author lists ‘simple and affordable IT enabled solutions' such as online banking and electronic invoicing in the ‘finance and accounts' category; and Web site creation and maintenance, and digital marketing in the ‘sales and marketing' category.

Guiding the small entrepreneur through a ‘layman's IT audit' for the company by evaluating strengths and weaknesses under each category and then choosing the applications that will help in the immediate and foreseeable term, the author highlights the many ‘fashionable by-products' of technology deployment. “For example, employee swipe cards for entry into your premises is not a big expense. However, apart from the numerous other main benefits, the corporate quotient that it adds to your company's internal branding is quite significant.”

Recommended study for the eager SME player.

Design for performance

Among the many recommendations that Rajnikant Puranik offers in Maximum Oracle with Oracle Best Practices(www.shroffpublishers.com) is his counsel about naming.

Document ‘naming convention' and follow it, the author begins. The convention should cover not just the naming of tables and columns but also other database objects such as views, constraints, and directories, he adds. “Use names and abbreviations consistently across the database. The same attribute should not have different names in different tables. For example, column for rate of interest should not be named as, say, ‘roi' in one table, ‘intt_rate' in another, and ‘irate' or ‘rate_of_interest' in some other tables. Decide one name, say ‘rate_of_interest', and use it consistently.”

Understandable names

Puranik recommends the use of names that are readily comprehensible. He explains how names such as ‘asstcls,' ‘astclsid,' ‘astcd,' or ‘assetclasscd' for Asset Class Code — rather than a self-explanatory name like ‘asset_class_id' — can make life difficult. It is better to use meaningful names, even if they appear to be long, he advises.

Though tempting for the short-term benefit of having to type less while coding, it is not advisable to use very short names whose meaning the coder is likely to forget after a lapse of time, leave alone those who have to deal with the maintenance of the code, reasons Puranik.

One of the deciding factors for a suitable naming convention that he lays down, therefore, is whether a new person — say a designer, maintenance person, coder, reviewer, or auditor — not involved in the project earlier, is able to understand the database and the database code to a significant extent at first glance.

‘Great' coding

Another instructive section in the book is about designing for performance, where the author cautions that no amount of ‘great' coding can alleviate the adverse effects of poor design on performance.

Maybe one could make a difference of up to 20 per cent or so in performance by using various strategies, but to really make a dramatic difference in performance the poor design will ultimately have to be rectified, he notes.

“A design may be good from the angle of implementing business logic, and there may be several such alternative designs; however, they may not be good enough from performance angle, given the volumes or number of simultaneous users.”

For the hands-on tech readers.

Movie-making and software projects

We need a modern way of thinking about software quality management that accommodates our industry's 30 years of lessons learned and patterns of successful projects, declare Walker Royce, Kurt Bittner, and Mike Perrow in The Economics of Iterative Software Development(www.pearsoned.co.in) .

Stating that most successful software management techniques today steer software projects through the minefield of ‘uncertainties' rather than track against a precise long-term plan, the authors make a case for iterative lifecycles, constant risk management, objective oversight, and a ‘steering' style of leadership that demands creativity throughout the team, to deliver innovation on schedule and on budget.

Hollywood comparison

Hollywood movie production is cited as a comparison to software project management, thus: “Movie producers regularly create a unique and complex web of intellectual property bounded only by a vision and human creativity… Like the movie industry, we need qualified architects (directors), analysts (scriptwriters, designers), software engineers (production crews, editors, special-effects producers, actors, stunt doubles), and project managers (producers).” Also, as in the movie industry, it is necessary to get increments of software into executable form (get it on film) to make things tangible enough to assess progress and quality, the authors analogise.

Of value is the insight in the book that software management is more accurately described as a discipline of software economics rather than software engineering. Because, day-to-day decisions by software managers (like those of movie producers) are dominated by value judgments, cost tradeoffs, human factors, macroeconomic trends, technology trends, market strength, and timing, the authors explain. They remind that software projects are rarely concerned with precise mathematics, material properties, laws of physics, or established and mature engineering tenets.

Suggested study for software engineers.

Tailpiece

“After we ran our new software that measures the degree of employee burnout, we realised our blunder...”

“Big bugs in the program?”

“No, a fire broke out in the office!”

dmurali@thehindu.co.in

comment COMMENT NOW