New Programming Methodologies
On September 16, 2005 a number of regional IT Executives and faculty from the University of Akron's College of Business Administration held the discussion on new programming methodologies. During this session, the focus was on “lightweight” programming methodologies, emphasizing Agile Programming (AP). Topics discussed included:
- How to best make use of consultants when starting an AP trial or program
- How AP can deliver improved estimates for project duration and staffing
- The role of "iteration managers" and Program Management Offices, and how management changes when using AP
- The crucial role of testing and quality assurance people with AP
- How maintenance fits in the AP paradigm
- Other issues regarding AP, “lightweight” methodologies, the influence of Sarbannes-Oaxley, and achieving CMM certification.
The firms that have begun using AP have had positives results so far. While it was agreed that the traditional “waterfall” method works very well for projects with well-known and well-understood specifications, AP is a highly promising technique to deal with the necessity of changing specifications in a dynamic business climate.
On November 4, 2005, a number of regional IT Executives and faculty from the University of Akron's College of Business Administration held the discussion on IT Recruiting and Retention. Firms who now wish to recruit IT personnel face many challenges, including: how to evaluate the skills and compatibility of prospective employees, where to find them, and what role the HR department should play in evaluating technical people. Many firms focus on hiring long-term employees while using contractors to plug holes or for short-term work, but younger employees may not be interested in careers in one place while many in the “baby boom” generation are retiring, taking their skills (including ability to work on legacy systems) with them. Replacing employees who leave can be more expensive. Globalization makes remote teams the norm, facilitating telecommuting, but eliminating any good meeting times. Firms enhance the work experience with extras such inexpensive day care, a laundry delivery service, flextime as possible, etc. Together all of these approaches constitute a strategy that emphasizes, to less or more degree, concern for productivity and the individual, and length of employment. The IT Exchange discussed details about these issues in the context of a framework that evaluates various HR/IT strategies.
On January 27, 2006 a number of regional IT Executives and faculty from the University of Akron's College of Business Administration held the discussion on Emerging Technologies. With the speed, complexity, variety, and sheer volume of new technologies that appear every year, firms use a variety of techniques to track what is happening. Communities of practice dedicated to following certain technology areas and rotation of developers through R&D roles may help develop a culture that embraces innovation. While IT should have the expertise to lead the business side to new technologies, evaluate how they fit into the existing infrastructure, and help develop business cases for them, the business side should provide the actual justification (be it ROI or not), for their use. Firms should be ready to pull the plug on pilot projects that are not working out. Among the list of new technologies discussed was Service Oriented Architecture, which can involve reuse of internally created objects and use of objects created by others, including major vendors such as SAP and Oracle.
The application of SOA is now becoming a reality in many firms. It holds out the promise of much greater business process flexibility and visibility, and increases in efficiency by reusing work. Cliff Donoughe of Accenture outlined the key architectural components of SOA, and summarized some key advantages that he has seen firms achieve using it. With the commitment of Oracle/Peoplesoft and SAP to re-architect their products as sets of services, we are poised to enter a new era of software development in which services, either internally developed or provided externally, will play a major role. Simple steps to get started were outlined: writing new programs as web services themselves, starting with technical services that can benefit the IT function as a means of learning, and creating Centers of Excellence to promote SOA use in the enterprise. Mastering SOA can take 6-18 months, depending on firm size, and may require substantial investments in hardware, software, and training. However, strong ROIs have been observed. The consensus of the group was that SOA is an important emerging core technology.
Our wide-ranging discussion covered “a day in the life of data warehousing,” and was far more extensive than can easily be summarized. Topics and insights included:
Data Modeling and Off-the-Shelf Packages: The main problems with data modeling include how comprehensive the scope of the project should be, and getting various different constituencies to agree. There are pros and cons of the bottom-up approach using Data Marts and the top-down approach using a single Enterprise Data Warehouse. Using the data model of an off-the-shelf package can be useful, but should be seen as a starting point.
Governance and Re-engineering: Strong governance is required, both for the project itself and to deal with issues that may arise with more fundamental business processes. Cross functional teams must be empowered by business ownership of the project. Data warehouse projects may reveal business process weaknesses, and so may entail business process re-engineering.
Quality: Data warehousing projects are worth little unless the underlying data is accurate and comprehensive. Data quality should be considered well before the data are to be loaded. Early use of a profiling tool can save time and effort later.
Globalization: Globalization presents particular problems, especially with the need to have multiple translations in the enterprise-wide data warehouse.
End Users: Recognizing different types of end users and providing appropriate training is a must.
Security: Although sometimes difficult to administer, role-based security allows necessary distinctions deep into the data.
On June 13, a number of regional IT Executives and faculty from the University of Akron's College of Business Administration held their regular meeting of the IT Executive Exchange. The focus of the discussion was on IT Skills and IT/IS education. The topics that were discussed included:
Key components and gaps in the undergraduate IS curriculum
Entry level career options
Trends in IT development
General and specific skill sets
Skill considerations in a global environment
Providing practicum based knowledge to students
Development skills are essential to becoming a good analyst. This may vary with the orientation of the IT group. Companies which tend to offshore most of the coding have a greater need for analyst oriented skills. General soft skills such as communication, presentation and negotiation should accompany coding skills. IS courses should emphasize general project management concepts throughout the curriculum. Good coding and data skills often are a transition point to more senior business analyst or technical positions. Students can gain real world experience prior to graduating internships, practicum oriented classes, guest speakers and life cycle projects.
Creating a strong service climate, a new concept to the IT field, is a cornerstone for marketing IT to the business side. Unlike culture, climate is something that can be changed by deliberate managerial actions. The necessary but not sufficient condition for marketing is a strong service climate, i.e. meeting and exceeding users’ expectations. The IT governance processes in place are a key element of this activity. Marketing itself involves communicating what is being doing, getting user feedback, and managing expectations.
Among the many good ideas shared included the following:
- getting everyone in IT to take responsibility for good service;
- upper leadership setting the example;
- sitting users and developers together to ensure strong communication;
- using this same principle to ensure appropriate communication at appropriate levels all the way to the CEO level;
- engineering the budgeting process for flexibility and transparency;
- understanding the bigger picture about how all requests fit together;
- publicizing real-time project status on a portal;
- implicitly and explicitly managing word of mouth about the IT function;
- using blogs, open houses, IT fairs, technology briefings, surveys, and interviews with users on site;
- explicitly educating users so as to set user expectations.
While budgets have not been declining at the firms who participated in our discussion, there are more and more demands to do more work and to get more bang for the IT buck. Good alignment—e.g. doing what the customers want, being in tune with the strategy, coming in on-time, on-budget, on-function—leads to bigger budget increases. What the IT department gets can be distorted by convoluted budget processes. For these firms, the IT spend outside the IT department is not a significant factor. Capitalizing software development may be one budgetary way to get more with less.
A key to doing more with less is understand the value that IT provides. Most firms do not track this adequately after the system has been installed. Having too much headcount is a pitfall. Contractors are a way out, but should be used short-term, and as a means of teaching your people new things. Contractors should be excellent “fixers” who eliminate costs you would incur from major problems. By the same token, hiring outstanding people prevents merely adequate people from being a drain on the IT department, leading to more for less. Giving employees competitive salaries, opportunities for growth, and food (offered only partially with tongue in check) are good ways to keep employees happy, allowing managers to ask more of them. Doing the project right the first time, including getting change management right, reduces costs. Excellent project
managers on the business and IT sides with accountability are important for success. Prof. McHenry presented four strategies for managing in a downturn. All the participants have seen and used them all, but not as strategies for the entire IT department at once. Rather, they see a life cycle of systems development which may have to be extended when resources are tight, to a phase of squeezing the most out of the infrastructure, to paying mainly for maintenance, to reconsideration of the system and possibly cleaning, house. A firm with no mandate for growth at all, such as one being taken over, might resort to just one strategy such as only maintaining legacy systems.
The ITEE Group discussed the pros and cons of moving to Microsoft Vista and Office 2007. The issue of when and how to upgrade hardware and software is a core responsibility of all CIOs. Thus it was not surprising that we had a large turn out for this meeting and many people participating. Some of the questions that were addressed included:
What is the interoperability of Vista and Office 2007 with other programs?
How does the transition to Vista/Office 2007 inside the organization affect all of the electronic relationships with firms outside the organization?
Should firms go to Office 2007 on Windows XP?
Should the transition be done as a big bang (all at once), or little by little?
Other applications in the firm may have embedded Microsoft tools. How will the transition to new versions affect them?
Vista and Office 2007 offer a stunning new visual landscape. Users may get used to this at home and demand it at the office before you are ready to transition to it. Not only will expectations be raised, but there will be a need for significant amounts of training. How much will this cost?
Where are the nuggets within Vista and Office 2007 that will provide significant cost savings of enhanced revenue streams for firms?
Microsoft seems to be moving to a policy where everyone will have to have “software assurance,” a program that “provides” updates on a regular basis. Without it, you do not have any support. What are the implications of this policy shift?
While not yet having definitive answers to any or all of these questions, the group shared practical knowledge and ideas to date.
The focus of the first part of discussion was on the way in which the upgrade suite of products for Microsoft Vista, Office 2007, and others related to collaboration interact and provide a platform for collaboration. A high-level but detailed description was given of these interactions for SharePoint and the things it connects to, including Excel, SQL Server, Outlook, Exchange, Windows Mobile, etc. Some time was spent on how SharePoint may access backend systems and provide greatly simplified means of data reporting, including on dashboards. The pros and cons of Groove were examined in light of the functionality of other parts of Office 2007. While Microsoft has provided some forward and backward compatibility, so that it is possible to run some older versions with some newer versions, there are new features in some of these products that appear to be exciting and deserving of serious consideration for upgrading.
The second part of the discussion revolved around ways to justify upgrading. Several concrete examples were given, including using SharePoint as a strong interface for collaboration based on Microsoft Project 2007; providing users with more unified user interfaces by replacing native vendor tools with SharePoint as the portal; using the improved forms tool to implement time reporting; sharing of calendars through SharePoint; and external and internal collaboration revolving around joint document management. It was asserted that process improvements may drive the need for aspects of these tools, which will then drive the justification for upgrading. It was also asserted that collaboration may not, in fact, be a prime driver for upgrading; rather, it may be aspects of the user interface, such as “the ribbon,” that prove decisive. Few participants brought any concrete data about savings achieved by using the new tools. It appeared that many are planning their strategies now.
This session was a rich examination of the need for a document retention and destruction policy, for understanding new Federal rules pertaining to the discovery and provision of electronically stored information (ESI), and for understanding how those rules may apply in specific cases discussed by the participants. The concepts of “claw back,” “quick peek,” and “safe harbor” were explained. Safe harbor means that if you are following your policy in good faith, you should not be held liable for information that is not recoverable. This changes when a lawsuit starts or is known to be imminent, at which point you should put a “litigation hold” on the destruction of any relevant ESI. The usefulness of a litigation toolkit, which provides templates and procedures for what to do when a lawsuit arises, was also discussed.
After a detailed examination of these issues by invited speaker E. Stewart Moritz, participants discussed many questions and practices surrounding e-discovery, document retention, and backup policies at their firms. Being prepared for litigation means understanding where any and all data are stored, which includes understanding the official and de facto ways that end users are storing data. With storage needs exploding, adding another requirement that suggests defensively storing “everything” could be prohibitive. New technologies may make pinpoint storage and extraction more feasible, leading all the way to a day when retention and destruction gets folded not only into information life cycle management, but knowledge management more generally. Lawyers do not necessarily understand these technical issues, so it behooves IT to be ahead of the game and engage with the lawyers to put policies and practices in place before lawsuits arise.
Disaster Recovery and Business Continuity: What Have We Learned?
A major new issue of concern is regulatory compliance with regimes under Sarbanes-Oxley, HIPPA, and others, which moves the firm from business-driven to business-and-regulation-driven disaster recovery/business continuity (DR/BC). Since regulations change frequently, this seems to lock in the need for expensive consultants on a yearly basis. Outsourcing becomes trickier. Although estimating costs of DR/BC is difficult, regulatory compliance has forced the issue of DR/BC up to the high executive level, where it belongs. DR/BC must be championed at the highest levels of management. Strategies were discussed such as N+1 redundancy; hot, warm, and cold failover; replication; using backup devices for load balancing; and using third party firms for offsite storage, operations monitoring, and short-term operations. Identifying resources that you now hire for short term consulting jobs as people to go to in case your own human resources are diminished was cited as an effective strategy.
Some areas of IT are now coming under more scrutiny for DR/BC. Information on the desktop that is important enough is being subject to enterprise backup, and encryption is being installed on laptops and desktops alike. In specialized cases email may be considered critical, but it is generally not included in the immediate DR/BC plan, and using a third party firm to store and forward the email can eliminate worries altogether. All the firms present use offsite storage through firms such as Iron Mountain.