Client-Server Computing is all around us.  By reading this web post you are experiencing client-server at work and there are countless examples and growing uses for client-server computing, especially as the popularity of cloud computing increases. So what is client-server and what are the differences between fat and thin clients?

Client-Server Computing leverages the capabilities of networking such as that used in your office, home, and the World Wide Web.  As the computing environment has evolved from mainframe systems with dumb terminals to a network of powerful desktop computers, corporations needed a way to take advantage of the computing power on both ends of the network, hence, client-server computing. By replacing mainframe systems which use dumb terminals, with a client-server architecture, a company can take advantage of the distributed computing power in the clients (the desktop PCs), rather than just using dumb terminals that require the server to do all the work.  Additionally, centralized data is still accessible to everyone who needs it.  It is a best of both worlds approach to computing.  The client-server model also offers unprecedented opportunity for growth, scalability, and concurrent multi-user access to central information.

Fat clients take the majority of the responsibility for the application logic, which frees the server from much of the work.  This approach has several advantages to the thin client approach.  Some of which are; a greater flexibility in application design and functionality, an increase system stability when updating application logic, and fat clients are generally easier to because they are client specific and do not have to be compatible with various client types as in a thin client system.

Thin clients, on the other hand, have little if any responsibility for application logic, which place most of the burden for the application on the server.  This provides several benefits distinct from the Fat Client system approach.  Updating the application logic is more easily accomplished since only the server needs to be updated.  Thin clients require less knowledge of the data on the server side, which contributes to a higher level of encapsulation and data integrity.  Thin clients are generally easier to debug and manage since the application logic is in a central location, the server.  Data management is also easier for the same reason.  Network bandwidth is less of an issue because most of the processing is performed on the server where the data resides rather than transferring data across the network to the client.  More robust applications and consistent performance from user to user, or “universally compatible” applications, are another advantage of using a thin client system.  

A client-server approach to a networked computer system provides a scalable and flexible system, which allows a company to maintain centrally accessible information, while at the same time taking advantage of the available distributed computing power that exists in the desktops throughout the company.   The client-server approach also improves the use of available computing power by separating functions and processes performed and delegating them to the appropriate and most capable machine.   

This idea of sharing resources across a network is location agnostic.  The user does not need to be aware of the how or where the process is being completed.  This encourages encapsulation of data, which also facilitates security, stability, and data integrity.

The Kerberos protocol (named for the mythical guard dog of Hades) can defend against a variety of different security attacks.  The Kerberos protocol uses a system of tickets and authenticating applications to control access to network systems.  As messages are sent back and forth between the user, Kerberos, and the requested network services the messages are encrypted and there is always a piece of information missing from the message that only the receiver has.  This system makes these messages useless to anyone with malicious intent who may be eavesdropping on the network and trying to steal information or impersonate services. 

When a user wants access to a secured item on the network, they start the K-Init application to get a ticket-granting ticket.  The user enters their user name which is forwarded to Kerberos.  Kerberos cross references the user name and encrypts a message containing the user’s ticket-granting session ID with the user’s password.  This encrypted message prevents any rogue users from stealing a password in transit across the network.  The message is only unlocked if the user enters their password correctly in the K-Init application.

After the user unlocks the message sent by Kerberos, they are given a ticket-granting ticket and a session key.  If a user wants to access services, they send a message to Kerberos containing an authenticator message, the ticket-granting ticket, user name, user address, and the service being requested.  When the message authentication is confirmed, and the message is encrypted, the ticket-granting service gets a copy of the session ID share by the user.  Then the ticket-granting service makes a ticket for the requested service, determines a session ID between the service and the user, and then sends this message encrypted with the ticket-granting session ID that the user already received from Kerberos. 

This packet is encrypted with the session ID which only the ticket-granting service and the user have a copy.  This prevents the stealing of the tickets which authorize access to services. 

In order to prevent someone from impersonating a service and stealing information, the Kerberos protocol requires mutual authentication.  First, the authentication described above is used to authenticate the user to the service.  Before any information is sent to the requested service, the user machine waits from confirmation from the service.  The service sends a reply packet encrypted with the session ID which was granted by the ticket-granting service.  If a fake server receives these packets, it does not have the session ID and can’t properly encrypt a reply message.  If the user doesn’t receive the reply, no information is sent and the operation times out.

Have you historically understood the need to improve data quality in your company, but despite your efforts, have not addressed and resolved the root cause of data quality issues?  You are not alone. 

In my work with Fortune 50 financial firms,data quality is a frequent topic of discussion and can seem as unachieveable as finding the Holy Grail. Typically firms will execute and deliver on several tactical fixes that help discrete data quality or metadata problems, but fail to systemically resolve the issues.  Additionally, approaching the problem from an tactical point of view is neither scalable nor cost efficient. 

In most cases resolving these data quality issues are both complex and require horizontal teams across the organization.  So what does an effective horizontal team look like and what is their function?

A horizontal data management team is chartered to:

• prioritize the strategic focus for data quality management and data stewardship
• sponsor a horizontal (end to end) understanding of the data from sales to service
• identify data stewards or end to end data owners for high priority data sets
• identify and publish controls and processes to improve both operational and management reporting data
• identify required infrastructure and assign day to day ownership of data quality
• integrate data related projects to ensure data consistency

Assigning common roles and responsibilities to a horizontal team is a key step in improving corporate data quality.

Congratulations!  By this step you have made the commitment to protect your most valuable data assets, identified key stakeholders, established regular discussions with these stakeholders, and identified the scope of your governance initiative.

Remember a key to success will be keeping this small, gathering senior level support, and celebrating frequent successes.

The governance model has several components; business elements, actions, metrics, agents.

In your stakeholder meetings you likely have discussed the scope of your initiative and through that discussion identified the key business elements that need governance.   These should be the business’s most important or most used data.  It is also likely to be the most confidential or most controversial.  And for all of these reasons each line of business, business department, or analytic team probably has their own data store and their own data definitions for these (therein lies the problem that you are working to solve).

Next, you and your stakeholder group will define the actions or operations that will be used to align these business elements across the disparate teams, data stores, or reports and get a common definition and common method of handling this data.  How will your group make decisions, process approvals, and reconcile differences?

It is critical at this step to be selective and pick the low hanging fruit and the items with the biggest bang for the buck.  Don’t try to define actions that cover all situations or you will find yourself endlessly meeting and discussing to account for every possible scenario.  I have seen many data governance initiative die at this point because teams cannot agree.

Next, we focus on metrics and the agents that will enforce the model you create.

A  Data Governance framework is comprised of the following parts;

• Oversight Board
• Stakeholder Forum
• Process Agents
• Business and Technical Liaisons
• A Repository
• Defined Focus Areas

Approaches that begin with spending money are doomed to failure, so start by building the portions that don’t require capital expenditures yet have real business impact.  The Stakeholder Forum is a perfect place to start for both of these reasons.

Stakeholders are the people, functional groups, and teams that depend on the data within the scope of your governance initiative.  To incubate this initiative, be sure to hand pick stakeholders that are already active in data.  Business analysts make excellent candidates because the quality of their reports and analytics are directly dependent on the data you are trying to govern.

Establish a roundtable with these stakeholders where you jointly identify the business needs and justification for a Data Governance function in your organization.  Next, define the role of Data Steward and leverage the Stewards to solve problems that arise with your data, such as conflicting data definitions.  Finally, establish some training, even if just simple documentation. 

Remember to start your Data Governance program by identifying the business’s most important or most used data.  Select a team of folks (such as business analysts) that use and depend upon this data and therefore have a vested interest.  Then leverage this team to create a Data Stakeholder forum and define needs, solutions, and training.

The topic of Data Governance can be abstract and difficult to define, furthermore, it often fails because of a lack of business focus.

Don’t let these challenges keep you from managing your extremely valuable data assets. Data Governance, done properly, establishes a foundation for defining, managing, changing, and integrating the Data in your organization. It enables the processes that will care for your Data and outlines the organizational decisions which impact Data’s meaning and value.

In this series of posts, we’ll outline the steps in building a framework to give concrete meaning to Data Governance in real business terms.

Your starting point is to create a Data Governance Framework which defines the essential scope and supporting processes. The goal is to align business needs with the governing functions, ensuring that the most important and most necessary pieces are established first. Move one step at a time and do not try to tackle the entire framework at once (it’s too daunting).

Before you can obtain the support of your executive management team, you first must identify critical business data needs and then pick the one most relevant to your business. If you are unsure where to start, try in sales or financials. Find the data elements are most controversial, most used, most confidential, or most regulated. Use these examples to build your business case and your sales pitch to gain executive leadership support for the concept.

Assuming you have support for the initiative, establish your Data Governance Organization. This is the authoritative body when it comes to Data decisions. Most importantly, it can be virtual and does not require additional staff (avoiding additional costs will be key to your success). This organization is responsible for the guidance, planning, and stewardship of your Governance initiative and we will define these responsibilities in more detail in the next post.

Let the framework serve as your roadmap to creating and launching a successful and business focused Data Governance program.

Do you have a data problem?  Don’t feel bad, most companies do.  It seems there is either too little data or you are swimming in meaningless mounds of data.  Maybe you have data but can’t access it, analyze it, or report on it easily.  If you want to improve your data you’ll undoubtedly be faced with the need to make a business case for data quality.  This can be tough to justify and unfortunately you will have to make choices about which problems to fix and which to leave for later.  In order to make the best decisions, you will need some tools to express the impact that poor quality data has on your company.  Here is a quick guide to help you get started. 

Begin by attempting to quantify the impact that a data quality issue could have on your business.  Consider both the area of the company that is affected by the data you are investigating and the number of users impacted.  Considering both dimensions will help you assess the severity of data quality impacts to your business.

1. Data that impacts legal and/or compliance reporting or management should be marked critical.
2. Financial reporting data, which should also be rated critical regardless of the number of users affected. Data that impacts your GL reporting always warrants a critical rating.
3. Operational data (used for daily management and reporting) is certainly important, but the severity of the impact can range from slight to critical depending on the number of users or business areas impacted. Consider the case when a few users are impacted and maybe their job is less efficient because of the issue, but the business does not grind to a halt. This would be rated a slight or possibly moderate impact.
4. Analytical data used for forecasting, modeling, scorecarding, etc. generally would have slight or moderate severity impact on your business. However, in the case where a large percentage of the users or quantity of data has been affected (say greater than 5%) the impact could be rated serious.

 By understanding the severity of the impact that data has on your organization, the areas affected, and the number of users impacted you will identify which data you can trust and which data need stronger controls and possibly clean up.