Click here to read the entire SearchCIO article. Registration required.

Here are some of my posts. You can read them all by clicking here.

The Myth of Social Media

MIKE2.0 (Method for an Integrated Knowledge Environment) is an Open Source methodology for Enterprise Information Management that provides a framework for Information Development. The MIKE2.0 Methodology is part of the overall Open Methodology Framework. In May of 2010, I agreed to join MIKE2.0 as a featured contributor.

Click on the links below to read the entire articles.

• On Steve Jobs, Agile, and Meeting IM Needs
• Clouds, Data, and Technology Maturity
• Time for an Information Management Strategy?
• Experimentation, Open Source and Big Data
• A Primer on Data Matching
• The Missing Q
• Thoughts on the Chief Data Officer
• Neutral
• Visualize Your Data
• In Defense of IT
• Data Liberation: The Case For and Against
• The Sea Change and Enterprise 1.5
• How Open is Too Open? 
• The Data Curves
• Metadata and Collaborative Filtering
• Voltaire, Apple, and the Myth of Perfekt
• On Gambling, Data, Google, and Ethics
• Who will manage Big Data?
• Organizational Mind-Sets, Michael Jordan, and John McEnroe
• The Data Paradox
• Healthy Disrespect
• The Quiet-Eye Period
• Don’t Tell, Don’t Ask
• Football, Fish, and Leadership
• Office Space, Data Cleanup, and A Radical Approach
• Know What You’re Signing Up For
• Data Error Inequality
• Look at Your Data
• Watson, E-mail, and Semantic Technology
• Systems Thinking
• The Case Against Triage
• Ignorance and Data Management
• Data Management Tips for the Growing Organization
• MDM and the Vacuum Effect
• Under the Radar
• Enterprise Information Architecture: No Small Endeavor
• Clowns
• Saying Goodbye
• Tweety Bird and Aha! Moments
• Jerry Macguire and That Report
• Dummy Deadlines and Transparency
• Email is not collaboration
• ETL Checkpoints
• Do you know your data?
• The Battle for 60
• Agile Challenges and the Great Divide
• The Semantic Web, Part V: Getting Ready
• Part IV: A Semantic Web Case Study
• Data Cleanup: Michael Clayton and The Consultant’s Role
• Part III: The Semantic Web and Complementary Technologies
• The Semantic Web, Part II: The Business Case and Customer Service Implications
• Customer Service, the Financial Industry, and the Semantic Web, Part I
• Resource Mistakes, Part IV: Expecting Complete Obedience
• Resource Mistakes, Part III – Silencing Dissent
• Resource Mistakes, Part II: Brian, Stewie, and TCO
• Resource Mistakes, Part I
• The Worlds of Information Management
• What does it mean to be an expert?
• Charlie Rose, Customer Service, and the Master Twitter Record
• John Q. Public, Customer Service, and Information Management
• Collaborative Project Management
• The Case Against Collaboration, Part III
• The Case Against Collaboration, Part II
• The Case Against Collaboration, Part I
• The Enterprise 2.0 Consultant
• 8 Rules for Managing Complexity
• Are We Seeing the Death of Freemium Model?
• MDM 101
• Why I’m Bullish on Open Source

The reasons for, and statistics on, IT project failures are well known and cited. However, because so many organizations attempt to hide their dirty laundry, rarely do we see an insider’s account of the precise points at which a project derailed. In this Executive Report, a case study is utilized to examine these issues at one organization, along with data quality and data governance.

Click here to access a case study that I recently wrote for the Cutter Consortium.

Disclosure: You’ll have to provide some information to Cutter in order to download the document.

• In Praise of the Flat File
• Dual is a Four-Letter Word, Part 2
• Netflix and Dual Data, Part 1
• On Scheduling and Unstructured Data
• On Data Quality Sponsors
• The Urge to Purge
• Practices Smractices
• On ERP and Data
• On Data, Crises Mortgages, and Context
• Gimme Structure
• Signals and Noise
• The World Spins on Data
• Hamsterdam and Data Anarchy
• Memento and the Fallacy of Uncertainties
• Direct Data and The Royal We
• Where’s the data?
• What if?
• International Data Management, Part 2: Hofstadter’s Law and Money Matters
• International Data Management, Part 1
• Is Security Inhibiting Your Data Quality?
• Room for the Little Guy?
• Calculus and A Data Quality Equation
• Looking but Not Seeing
• The Indian and the Arrow
• That One Thing
• Why Watson Scares Me
• The Data Ownership Dichotomy
• Negative space, Miles Davis and Data Quality
• Driving Your Data
• The Fixer
• Elegance
• The Voice of Data
• Data Quality Incentives, Part V: Company Size
• Data Quality Incentives, Part IV: Expectations and Ownership
• Data Quality Incentives, Part III: The Limitations of Incentives
• Data Quality Incentives, Part II: When Incentives Lack Teeth
• Incentives, Part I
• The Limitations of Google
• What’s the big deal?
• When SMEs Go Missing: Four Survival Tips
• Hybrids
• Defending Your Data
• The Limitations of Band-Aids
• Returning to the Scene of the Crime
• Part 2, Lessons from DataFlux IDEAS 2010
• Part 1, Top 10 Lessons from DataFlux IDEAS 2010
• Too Much Club
• Formal vs. Informal Data Governance
• Data Management and Social Search
• Data, Priorities, and Muhammad Ali
• Baseball, George Costanza, and Unwritten Rules
• The Case for Studs and Duds
• Alexander Pope, Indifference, and Data Atrocities Revisited
• Half Measures
• Big Data, Small Data
• Talking About Data, part III
• Talking About Data, part II
• Talking About Data, Part I
• Continuous Partial Attention
• Master Data Mismanagement: An Open Letter to Many Fortune 500 CEOs
• Heat and Trust
• Potato Chips and The Myth of the Data Warehouse
• Data Quality, Social Media, and ROI
• Data Quality Starts on the First Tee
• Data Atrocities #2: The Data Fork
• Johnny Cash, Purging, and Data Atrocities
• No Whining: In Defense of Facebook
• What Clients Don’t Tell Each Other
• What Consultants Don’t Tell Clients
• What Clients Don’t Tell Consultants
• Employee Data Quality Issues, Part III: Date Challenges
• Employee Data Quality Issues, Part II: Social Challenges
• Employee Data Quality Issues, Part I: Address Challenges
• When Data Quality Breaks Bad
• The Future of MDM: A Non-Expert’s Perspective
• Data Quality Non-Believers
• Aristotle, Patrick Swayze, and People Issues
• Data Quality Lip Service
• Foreigner and First Time IT Project Myths
• Rodney Dangerfield and Data Quality
• Simplicity, Enterprise Architecture, and Data Quality
• Organizational Culture, Data Governance, and The Death of ERP
• Distant Early Warnings
• Where Data Quality and Politics Unite
• Hostile Environment Data Harassment
• The Big Lebowski and Data Quality Culpability
• To Load or Not to Load: Confucius and The Argument for “All or Nothing” Data Quality
• Data Quality Windows
• Data Chaos and Five Truisms of Data QualityIs Security Inhibiting Your Data Quality?

Here’s the background:

Every organization uses software applications to support its business processes. Some organizations buy, some build, and some rent software as a service (SaaS). Buying and integrating proprietary applications are sometimes complicated by M&A activity. Acquired or merged organizations often use different applications and systems than their new owners. Find out why CIOs facing this type of problem should think long and hard when considering integrating disparate applications, and explore a case study that demonstrates the pitfalls organizations commonly face in this situation.

Read the entire case study by clicking here.

Enterprise Systems, Staff Reductions, and Employee Training
Systems do not exist in a vacuum. A “state of the art” system run by too few or poorly-trained employees poses great risk to organizations. No HRIS or payroll system can possibly catch every type of mistake. The current economic climate exacerbates this risk. With respect to headcount, layoffs increase the vicious cycle of risk to organizations:

• Organizations have an incentive to trim staff and reduce—if not eliminate—formal training and opportunities for end-users to learn.
• This solidifies many end-users’ bad habits and suboptimal processing methods.
• Many end-users’ responsibilities have increased significantly
• In the event of layoffs, more work among fewer employees means even less time for “cross pollination.”

Management should be careful when cutting “non-essential” employees, as they can quickly become essential. For example, an organization has four HR clerks to process paperwork. While no one clerk is absolutely essential, reducing that number to two now changes that equation. If staff reductions are truly necessary, organizations must ensure that departing employees’ daily responsibilities are both sufficiently documented and well-understood by others in the organization before they leave.

Organizations need to identify essential employees via succession planning. Which individuals can the organization not afford to lose? It is imperative that they are proactive; they should attempt to anticipate any key employee defections.

On the training front, organizations should strongly consider cross-training end-users in multiple functions. Two super users with substantial skills and a global perspective may be able to do the work of three or four limited end-users, especially if they are skilled in different automation methods. For example, consider Mary, an end-user who is very skilled at Microsoft Excel. Her organization has a Crystal Reports license, but no one really uses it. Sending her to a class would allow the organization to finally realize the benefits of Crystal; no longer would reports have to be cobbled together manually.

Read the rest of the article by clicking here.

Types of Systems

There are two types of major systems in financial services firms, with vastly different success rates and implementation challenges. The first type-client-facing systems-are outwardly focused. They connect bankers, financial planners, hedge fund managers, stockbrokers, and their ilk with customers. Examples include banking and bill payment, 401(k) management, remote deposits, derivatives trading, and position monitoring. While these systems have many different objectives, they have two overriding commonalities-they link customers and investors with their financial institutions and generate revenue in the process.

Not all systems in a financial firm are client-facing. Organizations’ back-office systems are inwardly focused on internal employees and daily operations. Customers never use or even see these applications. Examples include supply chain management, accounting, human resources, and payroll. Back-office applications-typically called enterprise resource planning (ERP) systems-record sales and purchase transactions, update inventory, and cut employee and vendor paychecks. Invoices, receipts, and reports can also be produced by back-office systems. Unlike their client-facing brethren, back-office systems generate no revenue; they support cost centers.

The different scopes and audiences of these applications result in different rates of success. Client-facing systems fail much less often than back-office applications. By and large, the challenges faced by financial firms with respect to enterprise systems are not materially different than those faced by retail, health care, or government organizations.

Back-office systems support the entire enterprise, not simply one function. ERPs have to handle a number of disparate tasks, the vast majority of which tie back to the general ledger (GL). ERP systems are tightly coupled with one another. A problem in one area will almost always affect another.

On the other hand, client-facing applications can be considered “best of breed” and often do not need to integrate with other applications. They typically are designed to accomplish one or a limited number of specific objectives: transferring funds, buying and selling stocks, and the like. Handling stock trades or dividends, for example, is much less exhaustive than managing an entire supply chain or paying employees in 48 states and seven countries. As a result of this limited integration, their development cycles are much shorter and their failure rates much lower.

SOA and SOX

Two recent and seemingly unrelated events have coalesced, resulting in more efficient software development and fewer system failures. The first is the advent of SOA, which provides methods for systems development and integration in which systems group functionality around business processes and package these as interoperable services. SOA also describes IT infrastructure that allows different applications to exchange data with one another as they participate in business processes. Service-orientation aims at a loose coupling of services with operating systems, programming languages, and other technologies which underlie applications.

On the regulatory front, due to SOX requirements, many financial firms no longer attempt to create their own internal systems. SOX’s increased audit requirements have resulted in many financial services firms using independent software vendors (ISVs) to build proprietary systems. Firms such as Infosys specialize in making or selling software, designed for mass marketing or for niche markets.

Due to the arrival of both SOA and SOX, many financial firms have abandoned internal application development and now deal almost exclusively with ISVs, who observe the following cardinal rules with regard to software development: Issues found later in an application’s development cycle are exponentially more time-consuming and expensive to fix than issues found at the beginning of the cycle. Unlike off-the-shelf applications, software developers can essentially build anything. Software engineers and coders do best with pristine development specifications, allowing them to accurately build the applications and functionality desired.

This second point is critical. Management at financial firms typically realizes that ISVs require comprehensive development specifications. Equipped with them, ISVs are able more rapidly to build-and modify-applications to better meet the needs of firms and their clients. This minimizes the traditional back-and-forth and decreases the amount of time required for financial firms to realize a return-on-investment (ROI) on their new applications. These successes build upon each other. The bank that successfully rolls out an ISV-created application is encouraged to develop more applications.

From a systems’ development perspective, the cumulative effects of SOA and SOX have been largely positive. Many financial firms that had historically created their own systems often failed for one simple reason. The best programmers and developers tend to work for software companies, not financial firms.

Financial firms that contract ISVs to create specific, client-facing applications typically realize a number of significant benefits.

Less Risk with ISVs

Weinrib Partners, a fictitious hedge fund, wants to create an application allowing its investors to wire money from banks directly to the fund. Weinrib’s managers decide to outsource development to an ISV. The application has one very specific purpose and the managers can very clearly articulate the application’s requirements to an ISV which, in turn, expedites development. Testing should manifest any and all issues because of the application’s singular purpose.

Weinrib launches its application to clients who no longer have to write and mail checks to deposit funds. It is important to note that Weinrib owns the application created by the ISV. As a result, Weinrib can control the application’s customizations and enhancements. If Weinrib’s customers request that the application integrates with QuickBooks and Microsoft Money, for example, then Weinrib can approach its ISV immediately about making this change.

Contrast the system ownership model with traditional ERP purchase and support model. Organizations that utilize SAP or Oracle as an enterprise system have no control over its delivered functionality. End-users can always submit vendor “enhancement requests,” but there is no guarantee that they will be adopted in future releases of the application. What’s more, IT departments that customize ERPs face a number of significant obstacles. For one, customizations typically invalidate vendor support agreements. Second, making a tweak to a general ledger program, for example, may break something else. Enterprise systems are very involved and contain many interdependencies. Finally, even a successfully implemented customization may go by the wayside after an upgrade or service patch.

In April of 2008, PNC completed its acquisition of Sterling Financial Corp. While there were many reasons for the merger, one of the more overlooked ones involved technology. Specifically, Sterling’s internal systems had become antiquated. Its senior management realized that the necessary investment to upgrade them would be cost-prohibitive.

Sterling is not alone in this regard. Many financial institutions have realized that the old maxim applies: “If you can’t beat ‘em, join ‘em.” Organizations with antiquated client-facing systems cannot re-tool by simply making a few, relatively inexpensive enhancements. More often than not, a complete overhaul is necessary. At a minimum, most financial systems today must comply with SOX requirements, integrate with external banks, offer customers a powerful and user-friendly experience, and ward off increasing security threats. Beyond these requirements, applications often need to do more. Rather than merely transfer funds, many applications offer data mining and business intelligence (BI) capability and allow agents, bankers, and other personnel the ability to customize offerings based on the individual customer’s financial situation. Added to this, organizations’ IT budgets are under a microscope.

Simon Says

While there is no secret sauce to building and implementing client-facing systems, financial firms tend to minimize failure rates by utilizing ISVs and extensively documenting business requirements. Seasoned ISVs allow firms to quickly create and roll out custom applications that can increase firm revenue, profitability, and ROI. With respect to enterprise and back office systems, however, financial firms should not try to build from scratch. They realize no competitive advantage from payroll vendors or employees. In this sense, financial firms tend to have many of the same issues as the rest of the corporate world.

• Computer World Canada. Click here for online version of the magazine. For a separate PDF of the just the article, click here.
• Military Embedded Systems – Click here.

Why are you here?

More than a metaphysical question, many organizations may recognize the need for consultants but remain unsure about how to use them. This article compares two of the different consulting alternatives–traditional and milestone–and the pros and cons of each. In a traditional consulting arrangement, a firm deploys a team of full-time individuals at a client site for forty hours per week, typically four days at ten hours per day per consultant. Conversely, under milestone consulting, a client employs a consulting firm to check in with them on a regular basis, ensuring that the project is both meeting its individual goals and, from a broader perspective, remains on track. A client will often utilize a hybrid consultant–equal parts project manager, techie, and application expert–to visit on site every two weeks or so. Now that the definitions are out of the way, let’s discuss each in more detail.

Traditional Consulting

Consultancies typically prefer this arrangement for a number of reasons. First and foremost, traditional consulting maximizes billable time and revenue. Second, and there is more than a bit of truth to this, consultants on the ground can better steer clients in the right direction throughout the project, manage issues, and ensure an overall smoother implementation than if they were not present.

On the downside, traditional consulting tends to be the most expensive option for clients. Also, many organizations face end-user availability issues. Client end-users are often overworked and too busy to spend time with consultants. Remember, end-users on implementation teams have day jobs while consultants exclusively implement the new system. While consultants can work independently, at certain points, client input is imperative. Consultants on site are billing regardless of whether their skills are being used efficiently or not. In the rare event that a project is running ahead of schedule, rare is the consulting company that attempts to move dates up or suggests that its consultants do not need to be on site for several weeks.

Milestone Consulting

Benefits of this approach include keeping costs to a minimum. Also, to the extent that the consultant’s arrival is known well in advance, end-users can focus on their day jobs during the week knowing that they will devote certain days to the new system, coinciding with the arrival of the consultant. In theory, this can be more efficient.

This method should be used judiciously, as it is rife with potential disadvantages. For one, there may be no one keeping an eye on the implementation on a daily basis, allowing goals and dates to fall by the wayside. Issues may not be broached in time to address them without impacting a go-live date. Also, the implementation’s flow may suffer. Projects that constantly start and stop often lose momentum. Projects with more interruptions have a greater chance of failure and milestone-based approaches tend to have this limitation.