Tuesday, July 21, 2009

IT poses an interesting challenge during reorganizations. Between security policies, differing hardware, and existing software, integration of two business units requires time and effort across both companies.

In a TechRepublic article (2001), Loraine Lawson offers the following suggestions for IT restructuring:

  • How many people are in IT
  • How many users are they supporting
  • What are common user requests
  • What skills are in use in your location

I would further amend these questions by applying them not only to the new, united company, but to the individual companies as well. They would end up looking something like this:

  • How many people are being combined into one IT department?
  • How many users are being supported, and how many will be supported in six months, and again in a year
  • What are the common requests today? What will they be in six months? One year?
  • What skills are currently in use? Will they still be necessary in six months? One year?

By answering these questions, the new IT manager or CIO can evaluate current staffing needs, and prepare for the needs of the united company in the future.

References

Lawson, L. (2001). Members offer advice on restructuring IT department. Retrieved on July 21, 2009 from http://articles.techrepublic.com.com/5100-10878_11-5033618.html

Thursday, July 16, 2009

Introduction

In their article "Best Face Forward" (2004), Rayport and Jaworski discuss ways in which companies can integrate humans and computers into a unified interface which interacts with customers. The thesis they begin with is that without specific attention, most companies develop disparate interfaces between departments, or even projects within a department. The goal of "reengineering" the customer-facing business operations is to achieve a unified system which provides customers with better service, and the company with better efficiency and revenue.

The field of Human-Computer Interaction has been growing over the past decades, as computers are becoming more powerful. Analysts are finding surprising results regarding customers preferences of machines over people, even in matters such as shopping assistance and customer service. Airline Customers have found that automated ticket kiosks have sped the process of check-ins, while many grocery customers appreciate the speed of the "U-Pay" style check-out lines.

The first step a business must take is to determine the type of customer interaction their customer expects. In cases where a service provided depends on creative handling of judgement or pattern recognition, humans have an edge over machines. However, if the service depends on achieving consistent results when dealing with repetitive tasks, a machine would have the edge over human.

With the development of the new field of HCI, however, care must be given to how humans perceive the interface. For instance, in Grocery Store Self-Checkout lanes, customers are pleased when it is fast and easy. However, according to Walters (2009), there are cases where confusing dialogs and buggy programming can cause more harm than good.

IT needs to work with the end users and potential customers to ensure that Machine-Based interfaces not only work uniformly together, but that they also work seamlessly with the human side of the business. In addition, the software developers should pay close attention to feedback received during development, in order to develop a system that is intuitively understood by potential customers and users.

References

Rayport, J. & Jaworski, B. (December 2004). Best Face Forward. Harvard Business Review, 82(12), 47-58. Retrieved July 16, 2009, Business Source Complete database.

Walters, C. (2009). Consumerist - Dear Kroger, Please Make Self Check-Out Suck Less. Retrieved July 16, 2009, from http://consumerist.com/5308408/dear-kroger-please-make-self-check+out-suck-less

Wednesday, July 15, 2009

As a software engineer, project proposals are available in spades. Learning how to evaluate business needs and technical needs is a basic job prerequisite (Parkinson, 2000). Parkinson explains that there is a significant difference between a technical requirement and a business requirement. An example of a technical requirement would be needing a new printer. A similar business process requirement would be needing a more efficient printing algorithm that cuts down the time spent spooling a project to the printers.



Business drivers can be broken down into “chunks”. For instance, an “Expense Reduction” driver may be broken into Customer Service expenses, customer acquisition\retention, efficiency, and other expenses (Machavarapu, 2006). Once the drivers are broken down, Machavarapu recommends assigning weights to the “chunks”, such that new projects can be evaluated for priority.



Finally, there is an array of reasons for beginning an IT project which should serve as red flags for engineers and developers. Reasons such as “Wanting to stay abreast of the latest technology advances” frequently translate into “Spend money on shiny new buttons”. Unfortunately, if this desire to advance technology isn’t tempered by legitimate business needs, the project may fail, or worse, prevent legitimate projects from receiving adequate funding.


References

Bernard, A. (December 26, 2003). Why Implementations Fail: The Human Factor.

Boehm, B. W. Quantitative Evaluation of Software Quality. In R. W. Selby, Ed. Software Engineering (p. 27). IEEE. Retrieved July 11, 2009, from
http://books.google.com/books?hl=en&lr =lang_en&id=ttaMIFv8bv8C&oi=fnd&pg=PA5&
dq=characteristics+of+quality+software& ots=yWkqT2mRFl&sig=Mj9mpFfLpWk4BkLvp4cz
M8ZhGU4
Google Books.

Machavarapu, S. (2006). Prioritizing IT Projects Based on Business Strategy - CIO.com. Retrieved July 15, 2009, from http://www.cio.com/article/22976/Prioritizing_IT_Projects_Based_on_Business_S trategy/1

Parkinson, D. (2000). Recognizing business needs can lead to new and repeat clients. Retrieved
July 15, 2009, from http://articles.techrepublic.com.com/5 100-10878_11-5027153.html

Pfleeger, S. L. & Atlee, J. M. (2006). Why Software Engineering. Software Engineering Theory and Practice (3rd ed. pp. 9-11). Upper Saddle River, NJ: Pearson Prentice Hall.

Monday, July 13, 2009

GoPrint Progress

GoPrint is undergoing it latest remodel and will be released in the next few days. New features include an all new Office 2007 look and feel, improved automation, and enhanced MailShop interfaces.

Of course, the well known interfaces to NCOA, CASS, Crystal Reports, and PrintShop Mail are being improved - both in operation and in quality assurance.

Contact Joseph Reynolds (josephr@intentdriven.com) for more information!

Intent Driven Designs provides IT support, Web applications, Windows applications, and Microsoft Access applications.

Sunday, July 12, 2009

New Websites

Intent Driven Designs has implemented four new MVC based websites:

Web sites for Judy Reynolds, Realtor - Texas Home Group Realty:
www.JudyReynolds.net (conversion from previous .NET site)
www.ConroeHomeListings.com
www.WaldenHomeListings.com

Conroe Masonic Lodge:
www.Conroe748.com

stay tuned for more!!!
(sites authored by Mark Reynolds, Senior Architect and Developer)

Saturday, July 11, 2009

Software Quality

Software Quality is a concept has been discussed and defined in a number of excellent books and articles. Granular-Level specific characteristics are numerous, and the weight placed on one aspect may differ from company to company, or even from project to project. However, with the assistance of the Pfleeger and Atlee text (2006) and a text from Selby and Boehm (2009), we can examine several generic properties which are relatively universal.

  • Portability
    This is a measure of how the degree of coupling with other software or hardware. Can the software be easily installed and transferred, or is there a complicated integration with 3rd-parties (eg. SQL Server, or a special hardware key-dongle)

  • "AS-IS" utility
    Does the software require heavy customization once it is deployed to the customer?
    • Reliability
    • Efficiency
    • Human Engineering
  • Maintainability
    In 2 years, will we be able to fix a problem or add new functionality?
    • Testability
    • Understandability
    • Modifiability

Human Factors


Bernard suggests that the most basic reason for an implementation to fail is due to inadequate training and preparation of the operators of the system. Having been involved in several different implementations of new software, I have seen both well-prepared and inadequately-prepared staff try to deal with new software. I would venture to say that Bernard is exactly right in saying that improper training is a huge reason why software does not succeed. It is my experience that users with a stake in the company don't WANT to see software fail, but they will unintentionally sabotage the new initiative with "Well we always did it the other way" attitudes, if they don't have a good reason to make the change.


References



Bernard, A. (December 26, 2003). Why Implementations Fail: The Human Factor.



Boehm, B. W. Quantitative Evaluation of Software Quality. In R. W. Selby, Ed. Software Engineering (p. 27). IEEE. Retrieved July 11, 2009, from Google Books.



Pfleeger, S. L. & Atlee, J. M. (2006). Why Software Engineering. Software Engineering Theory and Practice (3rd ed. pp. 9-11). Upper Saddle River, NJ: Pearson Prentice Hall.

Tuesday, July 7, 2009

So I REALLY hate the way that Entity Framework does the Eager Loading system. One of the biggest things gained from EF over legacy ADO was the fact that queries have compile-time checking. With the .Include(string s) method, we end up back in the same place we started.

I'm hoping things are fixed when .Net 4.0 finally releases.

Monday, July 6, 2009

I received the following error while trying to use Entity Framework to update an object.

The property 'AccessLevelID' is part of the object's key information and cannot be modified.

The object is a User, who has an AccessLevel foreign key.

The problem was in my code, which looked like this:

user.FullName = FullName;
user.LoginName = LoginName;
user.Password = Password;
user.AccessLevels.AccessLevelID = SecurityLevel;
user.Active = Active;

I was, in effect, trying to change the primary key of the AccessLevel in the AccessLevels table. Not good!

However, when I changed it to the following:

user.FullName = FullName;
user.LoginName = LoginName;
user.Password = Password;
user.AccessLevels = context.AccessLevels.First(level => level.AccessLevelID == SecurityLevel);
user.Active = Active;

Everything worked out.

The trick was setting the AccessLevel by treating it as an object. Almost like an Enum, but not quite.

Wednesday, July 1, 2009

At some point during your SQL Server development time, you will eventually create a database while logged in to the server with a login other than SA.

If this happens, your dbo user account will be mapped to the account which created the database (call it sa2 for now).

A year later, when the db goes into production, you decide you want the sa account to be the owner.

In order to do so, you will need to run the following query:

USE [TroubleDatabase]
EXEC sp_changedbowner 'sa'

References:
http://alghourabi.blogspot.com/2008/09/changing-database-owner-when-dbo-is.html