Imagine that! Quality of outcome (as well as long-term cost of ownership) is more dependent on the skill of the operator than the sophistication/power of the tool. Hmmm… I’m thinking we could take a lesson from roofers on how we approach management of software projects. Everyone gets enamored with particular methodologies, as if somehow these tools are more valuable than the people using them. It’s an appealing idea because if we can rely on a methodology to assure a good outcome, we can treat the people involved like commodities. Unfortunately, the roofers have got it right – a powerful tool in the hands of the wrong person simply means more damage to be repaired.

Remember, no software package is perfect – so the best way to avoid infections is to practice safe computing.  More on that topic in another post.  I’ve not been faithful about writing blog posts, and as I look back on my past posts, I think it’s because I tried to write too much in a single post – so I promise to be more concise in the future.

Now it’s time to dig a little deeper into how senior management can pull that lever to drive costs down and drive revenue up.  I’ll focus in this post on the cost-reduction side of the value equation.

First of all – eliminating IT costs themselves is clearly not of strategic value.  With IT spending (including amortized CapEx) at less than 5% for most organizations, any reductions offer only marginal (tactical) benefits.  Strategic cost reductions require using information in new ways to strategically affect operational efficiencies.

Even Nicholas Carr, in arguing that IT doesn’t matter (see my earlier post on Strategic Value of Information),  concedes the strategic value of new technology when the barriers to adoption by competitors is high.  His argument that IT is no longer relevant supposes competitive barriers no longer exist because the technology tools used for Corporate IT  today are so readily available and affordable. 

I don’t disagree with Mr. Carr’s assessment that ready availability has reduced the strategic value of IT tools themselves.  If you’ve read my post on the Home Depot Effect,  you already see where I’m looking to identify the key barrier to entry other than cost/availability:  Personnel who have the ability to identify and successfully implement strategic applications of those readily available tools – AND who have the organizational support they need to succeed.  More on that in a moment.

For the last few years, Lean methodologies have been hailed by advocates as “The Way” to increased operational efficiency.  The principles that are the foundation of Lean Manufacturing have been applied successfully for millennia by innovators in every trade and industry.  Key among these is the principle of eliminating unnecessary or redundant activity.  Another is looking at the broader impact of activities (which I alluded to in my discussion of Strategic Alignment of Objectives). 

Identifying the significant cost drivers in an organization involves a careful review of the core operating processes – whether for a manufacturing plant, or a service organization like a hospital.  If you’ve already developed efficient processes – how’s your error/defect rate?   Once major cost drivers are identified, a “trained eye” is required to see the opportunities to reduce or eliminate those costs through the strategic application of information technology.

Unfortunately, this last stage is exactly the point at which many organizations falter.  In my earlier post on the role of CIOs, I pointed to the bifurcation of the role of IT in organizations, and the relegation of IT in many organizations to the tactical role mentioned at the beginning of this article.  When IT is viewed/valued by just this tactical role, there is no opportunity for even the most gifted visionaries within an IT organization to drive meaningful improvements in the broader organization:  they don’t have the required management support.   Consequently, these individuals tend to leave the organization.

In those organizations where the strategic role of Information is embraced, and a capable CIO is engaged, the CIO is the “trained eye” and his or her experience and abilities, with appropriate organizational support, becomes the key to strategic advantage through their ability to help identify and implement improvements using information tools.

Of course, everyone uses information tools (software) these days – but not everyone is proficient.  Even those who are proficient with a particular tool may not know how to best apply the tool to a particular situation, or they may have developed their proficiency with the tool to solve a particular problem – not realizing a better tool was available.  Master electricians may not be as proficient as the sharp apprentice at a particular task, but they are more likely to know the best way to wire up a home than either the homeowner or the apprentice.  Mind you – to do a good job, he must understand the needs and wants of the homeowner, and cost-effective execution of the work may require skilled apprentices, but getting the homeowner what they (really) want within schedule and cost constraints requires overall mastery of his craft.

So too, the task of identifying and implementing IT projects that have strategic impact on an organization’s costs requires a master of information to synthesize a solution from the needs of the business and the available information tools. 

The “trained eye” of a genuine CIO sees the value/cost chain of operations in an organization differently than the COO.  Many of the work processes in today’s organizations are information-constrained.  Where a COO may simply accept the existing constraints, a CIO sees the underlying interplay between the constraints and the processes they limit.  My favorite example is the use of a sophisticated ERP system to receive goods:  A simple physical process, requires  multiple steps, often by multiple workers (or even departments) and using paper as the medium for coordination and communication.  This burdensome process is often accepted as a necessary evil – a cost associated with the benefits of better organizational control and visibility provided by the ERP system.  Sadly, many organizations fail to implement the simple automations available within their software, or through supplemental software that could reduce direct (labor) and indirect (error) costs.

Where in your organization are you accepting higher than necessary operating costs?  Start by asking questions where you see the following:

• Information printed from software, marked up by hand, and re-entered into the same or a different software system.
• That same process, but with use of a spreadsheet and e-mail instead of paper and intra-office mail.
• Any research of the status of processes, including calling or e-mailing participants in the process to find out “who has the ball”.
• “routine” rework, error correction, or research of discrepancies

This just scratches the surface, but you get the idea.  Research shows that we literally fail to perceive that which has become routine.  Many senior business leaders simply fail to see the opportunity to reduce costs because the costs “have always been there”, and thus have become invisible to their strategic vision.  Challenge your assumptions on what costs can be eliminated.  Question whether processes can’t be improved.  Invite a “trained eye” to work closely with you to help you see your organization differently, and uncover the cost savings hidden to your own too-familiar eyes.

Does this mean implementation of the initiative fails per se?  No, the software/network systems that are the vehicle for the initiative are successfully deployed – but the expected strategic or tactical advantage that was the entire purpose of the initiative often falls far short of the expected (productivity) results.

I have seen two primary causes for this shortfall:  unrealistic expectations to begin with, and resistance or non-participation on the part of the end users of the new systems.  I’ll talk about unrealistic expectations another time – today I want to focus on what I’ve seen drive user resistance.

The biggest factor I’ve seen in my almost 30 years of implementing technology-based process improvements is the misalignment of objectives I mention in my first paragraph.  We could get really deep into the psychology of all this, but my experience suggests we don’t need deep analysis.  I’ve observed that most employees in organizations have a clear sense of what the measurable results of their jobs are – from ordering material to assembling widgets, and they can tell when a process change is going to materially affect those results. 

Whether someone is a high or low performer based on some objective measurement, I don’t know any who want to have their performance drop.  Many things affect this drop in productivity:  training, testing, unfamiliarity, more steps, and more complex steps .  Some of these are short-term (e.g. – training), and others will never be eliminated (e.g. – more complex steps).  If the training is effective, short term, and the only material effect on productivity, it is easy to get employees over the hump and have them adapt to the change and buy into the new system – especially if there are measurable benefits to the organization they can see and take pride in as a result of their participation – and it just cost them going through training for a week or two.

The difficult situation is when processes are fundamentally change.  Most employees who encounter a new software package can get past the training and resume their accustomed productivity in what they see as their job – but what about situations where the entire flow is rearranged resulting in elimination of some roles and material changes to others?  In these situations, it is imperative that employee’s perception of their job be realigned with their new role – or they will conclude they are being caused to fail in their job because what they used to do is now less productive.  Never mind that and entire downstream role has been eliminated and productivity of the entire process has been improved 50% – they’ll only see the 20% hit they took against their old measuring stick and conclude the system is causing them to fail, leading to resistance, avoidance, and circumvention of the system in an attempt to maintain their perceived level of productivity.

With the right approach to communicating with employees, this situation can be avoided.  In situations where adapting to the change requires only a short-term (training) investment, it may be sufficient to point out the lack of impact (or positive impact) on the job productivity of the individual – reinforcing their sense of the importance of their job.  Where the change redefines the role of the employee – the communication must focus on enlarging the employee’s view of their job so they can actually see the perceived drop in their personal productivity (in the old role), as actually being an increase in productivity.

Here’s a simple example.  Let’s say that in a warehouse keeping track of lot-controlled items, paper documents are used to direct activity, with the typical lag and errors in data entry.  Let’s say this methodology carries a 5-10% overhead for data entry, and another 25% overhead in labor time to resolve discrepancies through researching errors, doing physical counts, etc. 

Let’s say the overhead of a system capturing real-time transactions at the lot level decreases the number of activities a worker can complete by 10%, but will eliminate the data entry overhead altogether, and reduce the overhead for discrepancy resolution to less than 5%.  Based on the employee’s current perception of their job, they will resist the system, because they see the 10% drop in their productivity.  This is especially the case if their supervisor isn’t expecting this drop in productivity and adjusting her evaluation of workers’ performance accordingly.  This can even get into organizational misalignments on a broader scale – for instance if jobs are segmented so that supervisors are incented based on KPI’s that represent only a part of the process.  Oops!  Now we are actually encouraging resistance to the new system!

If on the other hand, management/supervisory KPI’s are realigned to match the new process, employees have their new (and more important) roles clearly explained and matched to revised work expectations – then employees feel successful in their job performance with the new system and willingly support broad adoption.
It would be nice if this happened magically – if every employee could see the concise management presentation and immediately comprehend the implications for their role in various processes – but that’s not the way it plays out in most organizations.  To expect this would fall into that other cause of failure:  unrealistic expectations.  Instead, plan to realign measurable objectives in every job affected by the change,  and over-communicate to help employees throughout the organization understand their new roles and the new objectives used to measure them.

In the May 2003 issue of Harvard Business Review, Nicholas Carr put forth the argument that IT doesn’t matter any more.  Needless to say, a firestorm of debate ensued, and continues today.

So is IT really strategic?  I think so, at least in part.  In my blog post yesterday I pointed to a bifurcation of the role of IT within organizations where one role is truly strategic, and the other is the commoditized provision of infrastructure described so well by Mr. Carr.   I also cited Chris Potts, a leading IT strategist, who identifies four generations of IT strategy within organizations, and again, Mr. Carr’s thesis correlates well with the first two  generations.  This leaves the 3rd and 4th generation thinkers in a position of developing real competitive advantage.  More on that in a bit.

Mr. Carr cites various examples where organizations did use IT to establish strategic advantage.  His premise that the bulk of innovation in IT has already been delivered is on the mark if we consider only the existing categories of IT spending – but his own examples demonstrate that when companies innovate, they create advantage.   There’s an excellent article by Frank Bannister and Dan Remenyi on Why IT Continues to Matter that acknowledges the truth in Mr. Carr’s line of thought, but go on to point out ways in which innovation can continue to drive strategic value.

If the barriers to innovation are low, competitors will rush in – and perhaps this lends credence to Mr. Carr’s argument that our focus with IT should be to reduce spending .  In my prior post on the Home Depot effect, I assert that as tools in any industry become more readily available and easier to use, usage expands but genuine proficiency in using the tools declines.  What Mr. Potts calls exploitation, the 3rd generation of IT strategy, might be described as the conscious development and application of proficiency to the same IT tools availble to one’s competitors.  In this case the value isn’t in the systems themselves, but in the way the systems are used.  I can affirm from my own experience working with many clients the strategic value in better use of the tools they have.

What Mr. Potts describes as the 4th generation IT strategy (Fruition) I believe is truly heading into virgin territory for most organizations.  Others will catch up, but this is the inevitable course with strategic advantage – it doesn’t last forever unless you are managing a natural monopoly.  How is this done?  It starts with proficient use of your IT tools, but launches from there with a synthesis of tool use that is truly innovative in your market.  Perhaps it is a unique workflow enablement, perhaps it is a new form of collaborating with your suppliers or customers – that will vary between industries and individual companies – but it will only emerge with a deliberate shift in thinking about the nature of IT as a strategic advantage:  Shifting from the advantage of the tools themselves to the innovative (and proficient) use of the tools.

Hmmm. . . I have several client organizations in which the CIO position has been quietly downgraded to the VP or Director of IT, reporting once again to the CFO or VP of Finance or maybe to the COO or VP of Operations.  Certainly, there are organizations where the role of the CIO is considered pivotal, but even in those with someone carrying the title, the overwhelming majority of them are subordinate to the COO/CFO.

Were the CIO’s not up to the task?  Certainly in some cases, but I think the determinant in most cases is the degree to which organizations embraced the notion of information as a strategic resource.  Chris Potts, a leading IT strategist, identifies four generations of Corporate Strategy for IT:

1. Technology – a first movement into technology adoption, frequently driven by a need to have basic capabilities in order to respond to external pressures or constraints.
2. Efficiency – focusing on cost and performance of IT services
3. Exploitation – the organization derives value from using IT resources
4. Fruition – IT projects are viewed as a portfolio of investments in change yielding business results

There is evidence that a meaningful percentage of companies have made it to generation four, as seen by Mr. Potts’ poll of an audience at a European conference last fall.  What’s interesting is that more CIO’s identified their boards as having a 4th generation outlook than a 3rd generation outlook.  Of course the largest segment thought their board was stuck at 2nd generation thinking.  Why might this be?  I believe many organizations started into the third generation without a clear drive throughout the organization to enable workers to exploit IT resources, so they declared failure and pulled back to the comfort of managing the efficiency of their resources.

An article in CIO Magazine from 2006 on the “State of the CIO” I think identifies a challenge for organizations struggling to define the role and value of IT:  There are two distinct roles for IT, and IT organizations are increasingly bifurcating along that division.

One role is identified as a service-oriented or utility model for IT focusing on execution, and the other is a strategic role focusing on creating new opportunities for increased value of the organization.  The tactical role of execution is predicted to be ultimately overtaken by external providers who can be equally effective and more cost efficient.  I’m not convinced of that argument,  but whether the tactical execution role is outsourced or properly separated from and subordinated by the strategic role, I believe the key point for moving successfully on to generations 3 and 4 in Mr. Potts’ model is to separate responsibility for these two IT roles and re-seat the CIO as a strategic participant in the organization – leaving the IT Director to execute efficiently.

Who wouldn’t rather use a nail gun when framing a house than to swing a hammer?  Now anyone can do the work faster than ever.  Hmmm. . . More speed with same level of control means greater instability.  Think about it for a moment – when a carpenter working with manual tools a century ago made a mistake, it cost him a lot more time, as well as the expensive materials that were wasted.  Now, we are blessed with less expensive materials (in most cases), and it takes so little time to re-do our work that we can rush along and not worry about the mistakes until an inspector comes along to make us fix them.

Oops!  Talk about unintended consequences – the tract-home from the 1950’s that my in-laws live in across town is better built than the semi-custom job I had built in the 1990’s.  In the span of 40 years, the accepted standard of workmanship declined even as the tools made it easier than ever to do the work right.  What went wrong?

I believe it is simply easier to sell a product when it is promoted as the vehicle to better results.  And in the hands of a master craftsman, better tools do seem to provide better results – but they also make it possible for amateurs to do more, reducing the perceived value of the professional.  As we insist on paying less for the work (after all the tools make it so easy!), the average level of proficiency of the workers declines.

There are more tools in the hands of more users, but it has come at a cost.  There are three distinct aspects to this Home Depot effect:

1. Respect for professionals declines – because “anybody” can do the job
2. Average quality of workmanship declines – because employers are now hiring underqualified workers who are proficient with the tool, but may not know the principles of how to really use it effectively.
3. The total number of tool users increases dramatically – making it difficult to discern who the real Pros are.

I’ve been developing this line of thought for some time, and recently saw a similar line of thought tagged the cult of the amateur by Nicholas Carr in an article on his blog.  He illustrates how this principle plays out with approximately free online resources (like wikipedia) taking the place of more authoritative sources.  There’s an old maxim that applies:  When everyone is an expert, no-one is an expert.

When I learned to program computers, there were no in-line debuggers, no visual development environments, and compute-time was very expensive.  You had to really want to be a programmer to put forth the effort to learn the tools and the principles to use them effectively.  Access and visual basic made software development accessible to the masses:  Is it any wonder so much software development has been outsourced to lower cost markets? 

Here’s a thought to ponder:  the operating system under the hood of the slickest consumer PC today (Apple Mac) is Unix – an operating system whose fundamental design dates back to the earliest days of digital computing.  It may be dressed up with a slick user interface (and kudos to the engineers at Apple for their consistent commitment to innovation), but all the work of the machine is managed by Unix.  It’s clearly not the tools producing the superior results, it’s the superior skill of specific tool users that generates the superior results.

User Interface design is an interesting blend of art and science. Visual appeal is important, but not the end goal in most cases – and it can even detract from desired functionality.
 
We’ve all experienced products with great visual appeal that just don’t work for us, whether it is a sleek cell phone that feels awkward in our hand, or a stunning web site that is hard to navigate. Truly good design blends an appealing aesthetic with comfortable functionality for the user of the product – whether it is software or an espresso machine.
 
User interaction is the point at which software design diverges from traditional media. The only point of traditional media is to broadcast a message; the users’ only interaction is to watch and listen. In order for the message to be conveyed, the user must remain engaged (visually/aurally), so the focus of the designer often drifts from conveying the message to viewer engagement.
 
It is easy to recall TV advertising that missed the mark because the entertainment worked to keep the viewers attention, but failed to create a strong brand association for the advertiser. Similarly, a compelling visual design can miss the mark for software that requires user interaction.
 
Clearly user engagement is important, especially when the software (web site) is targeted at consumers for whom engaging content is part of the “payback” of using the software. Even so, the engagement is merely a tool – because as the “Dot-bomb” era of the late nineties hammered home: “Eyeballs” are no substitute for revenue.
 
So how can we avoid the trap of focusing on user engagement to the point that we lose sight of the ultimate purpose of the software? We have found that Stephen Covey’s habit #2 – “Begin with the end in mind”, although formulated to address personal effectiveness, can easily be applied to software effectiveness as well. Take a shopping cart as an example: If the goal is to present maximum advertising or cross selling before the customer becomes annoyed and leaves the site, that dictates a different visual design and input flow with more steps than an objective of completing a transaction as quickly as possible.
 
At Triact, we engage with clients based on that basic principle by asking leading questions at the outset and throughout the life-cycle of a project. At every point in an application where a user is provided with a visual or auditory stimulus, the design of the software should be informed by insight into what we want the user to feel, what we want them to do next, and what we want them to remember. The answers to these questions then inform our investigation of what information or cues should be presented, and how best to present them.

The actual user matters

This is pretty straightforward, at least conceptually, but becomes more difficult when the objectives of different stakeholders in a project collide. For example, much software for commercial users has been developed with the ends in mind of senior management, without significant input from the folks who will actually use the software.
 
I got my most valuable lessons in UI design in my first job as a software developer, because I was working for a small company, and I had to provide telephone technical support to 500+ customer users as well as designing/building/debugging the applications. Talk about an eye-opener! Business owners were buying these systems to meet their business objectives, but their staff people were the ones using the software. As I talked many of those staff people through the actual use of the software, the connection between support costs and usability of the software was hammered home in a very personal way!
 
Those early lessons in usability and maintainability have stuck with me and enabled me to work with all the stakeholders in a project (managers, users, developers, etc.) to arrive at designs that meet the competing demands of ultimate functionality and transactional ease of use.

Balancing multiple purposes

In order to arrive at a UI that accomplishes the ends of both Management and Staff (users), we have to ask those important goal-determining questions of both audiences, and reconcile the apparent differences. The users want UI’s to be simple and make their jobs easier – management may want certain business rules applied that tend to make user processes take longer and not be so simple. Often, the role of the software designer/architect begins with reconciling the competing objectives of those who dictate the workflows, and those who actually operate the software enacting those workflows.
 
Let’s take an example involving a PDA application for order picking in a warehouse. We have three different constituencies to satisfy. Management wants real-time transactions to the ERP system to ensure inventory accuracy, and they want to enforce FIFO consumption of goods. Users report they frequently arrive at a location to pick material dictated by the ERP system, and it’s not there, so they need a means of identifying and picking the same or an alternate lot from a different location – so they want simple interfaces that allow them to adapt on-the-fly to what they find in their work environment. On top of all this, the CTO in the company wants to use rich displays with on-screen (multi-field) input – using the stylus.
 
Can you hear the users groan? The last thing any of the warehouse users wants to deal with is a tiny plastic stylus to click on tiny fields on a screen in order to get their job done. In the abstract, the multi-field input seems like a good idea – but not to the actual users. Unfortunately, many software implementations have failed because users who find software hard to use will then find a way to not use it!
 
For this reason, we have championed the finger as the ultimate input device, long before Apple put the finger over the stylus for the iPhone. Below I will contrast examples of a PDA UI based on a multi-input, stylus-oriented design with a PDA UI based on a single-input, finger-oriented input paradigm.

Multi-input PDA UI

The designs below are an awkward mix of input fields, check boxes so small they require use of a stylus, and buttons that might be finger operable. The variety of input options accommodate al possible workflow choices for the operator, but when 95% of the time an operator is executing a linear flow – the presentation of complex input options increases frequency of errors.

Single-input PDA UI

In contrast, the PDA screens below follow a paradigm in which the upper portion of the screen is used exclusively to present information, the only buttons are finger-sized and at the bottom of the screen, and the only input prompt/field (if any) is at the bottom of the screen.
 
 

The same work-flow can be implemented with either UI paradigm, but the single-input model means the operator can focus their attention on the bottom of the screen and follow a linear and deterministic prompting sequence, unless they encounter an exception that requires them to refer to the information on the upper ¾ of the screen.
 
In the end, the client has the authority to override our recommendations, as was the case with the multi-input example above. Balancing the competing imperatives of multiple stakeholders means applying judgment regarding relative priorities and management philosophy that is best exercised by the responsible parties within the client organization. As a partner, we make sure we point out the strengths and weaknesses of different design approaches to the various stakeholders, offer our recommendation, then faithfully execute based on the decision of the client.

In contrast, the PDA screens below follow a paradigm in which the upper portion of the screen is used exclusively to present information, the only buttons are finger-sized and at the bottom of the screen, and the only input prompt/field (if any) is at the bottom of the screen. The same work-flow can be implemented with either UI paradigm, but the single-input model means the operator can focus their attention on the bottom of the screen and follow a linear and deterministic prompting sequence, unless they encounter an exception that requires them to refer to the information on the upper ¾ of the screen. In the end, the client has the authority to override our recommendations, as was the case with the multi-input example above. Balancing the competing imperatives of multiple stakeholders means applying judgment regarding relative priorities and management philosophy that is best exercised by the responsible parties within the client organization. As a partner, we make sure we point out the strengths and weaknesses of different design approaches to the various stakeholders, offer our recommendation, then faithfully execute based on the decision of the client.

Bottom line

Good design in the world of software UI’s depends on the same guiding principles used in other disciplines:
· Begin with the end in mind (for all stakeholders)
· Let form follow function (of the actual user)
· The client may not always right (in our opinion), but they are always the client
 
Become proficient at applying these principles to a wide variety of circumstances, and you’ll have many satisfied customers and users!

In particular, I’m thinking of Virtual Machines coming into their own in Microsoft-centric data centers, and the rise of Rich Internet Applications (RIA).

I think I’ve commented before on my observation that web applications (of the basic HTML sort), are a reincarnation of the old IBM 3270 block-mode terminals, albeit with a more appealing graphics skin on them.  But under the skin, the model is the same:  block mode communications, screen display and input management for that screen at the peripheral device, and all the “real” computing done on a centralized server/mainframe.

Hmmm. . . VM/370, the commercial incarnation of IBM’s CP/67 operating system, was the original Virtual Machine implementation – and it was wildly successful.  I am less surprised that we’re seeing a re-emergence of VM technology in data centers than I am that it took so long to get here! 

It shouldn’t be surprising that once we got everyone used to the recycled block-mode computing architecture that some of the same drivers behind the client-server paradigm ascendant a decade ago would re-emerge and indeed they have. 

RIA has all the benefits of a client-server architecture, with little of the downside.  The pain of client-server implementations was keeping all instances of the client software up-to-date when it had to be installed on all the users’ desktops.  Rich Internet Applications deploy from a centralized server – so a system administrator need only update the application in one place to reach all users.  RIA’s also have the advantage of leveraging localized computing resources to both offload the central server, and to reduce latency for the users.

Good RIA design follows different rules than HTML-oriented application design.  Now the designer must look for opportunities to cache information locally that will enhance the user experience.  This sounds simple, but can cause problems unless caching is implemented properly.  For instance – if I pull to my client a set of customer records, updating a record can produce unexpected results unless the developer implements correctly. 

Since updating the data on the server is going to require calling a web service of some sort, the developer may make the mistake of directly invoking the web service to update the customer record, but not the local customer record – so once the user exits the screen where the transient instance of the customer record was updated, it will appear as if the record wasn’t updated!

Likewise, a similar oversight could make it appear the record had been updated (because the local collection was updated), but the change was never posted to the server.  Ah, the joys of client-server development!  For developers who’ve spent all their time building traditional web applications, this can be a huge stumbling block.

One approach to avoid this problem is to construct all writable local data as a read/write cache and build a write-status flag into each writable data structure/object, and separating the updating of the local data (in the foreground application context) from the update to the server (which can run as a background process).   When data is loaded from the server, or successfully written back to the server, the write-status flag is set to “clean”, and whenever the object is modified by the local application it is set to “dirty”.  The background task then simply has to walk through the “dirty” objects and write them to the server.  This caching approach has the added benefit of allowing the operator to continue working even if there are minor connectivity lapses between the client and server machines.

The downside of this particular caching strategy is that the user may do considerable work without it being posted to the server – so some sort of visual indicator that data is “dirty” is a good thing, as well as a mechanism to save the “dirty” objects in a loadable form for future processing in the event the connection to the server is down for an extended period of time and the user wants to shut down the local client application.

There’s always a catch, so the point is not to find the one best caching strategy and stick to it, but rather to understand the best caching strategy for the specific circumstances in which the RIA will be operating.  The good news is there’s lots of good caching strategies to choose from – after all “the more things change, the more they stay the same”. 

Oh, and Kimberly’s is smashed together also.  Standard in the VoIP phone service we now have is the ability to set up multiple mailboxes, each associated with one of the sub-accounts on the internet service – and since I’d already set up e-mail accounts for all the family members with the prior AT&T DSL service which carried over to U-Verse, it was fairly easy to set up mailboxes for both me and Kimberly on our home phone, turn off the answering machine, and bingo – we each have individual voice-mail.

This is cool, but I think folks have been getting this same sort of magic with Call-Notes and similar VM service on Plain Old Telephone Service (POTS).  What’s cool for us is that we are able to link a cell phone account (on AT&T) to each of the mailboxes – so now whether someone leaves me a message in my mailbox on the home phone or on my cell phone – my cell phone beeps and tells me I have a message (and I get an e-mail alert as well) so I can pick up the message from my cell or home phone! 

If your household is like mine – this is a major convenience.   I’ll share more on the saga of getting all this wonderfulness installed and configured another day.   Cheers!