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.

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.

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.

In its simplest form, the problem is with the model, and we don’t mean the data model. What improvements drove the business case for the BI system in the first place? You did create a business case, right?

What measures are really driving profit in your business? How does your data warehouse improve the Key Performance Indicators you use every day to track the health and success of your business? If you don’t have the answers to those questions, the ROIs you seek will prove to be very elusive.

Your BI environment should assist you in monitoring and measuring your success against KPIs. Are the processes you manage improved by the information you are able to obtain from the BI environment? While ‘better reporting’ is one benefit of an adequately built BI environment, that isn’t going to cover the high cost of building one.

Now for the hard part – what KPIs are important? Does every department understand how the work they do impacts those KPIs? Does every department even agree on what the KPIs are? These questions should be answered ideally before you even embark on a BI initiative. What if you’re already knee deep in an implementation or have a ‘legacy’ BI environment? Consider a Business Intelligence Competency Center (BICC). A BICC should have one primary goal, and that is helping your organization achieve a Return on its BI investment.

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.

• 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.

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.

Business and technical leaders both have a responsibility when it comes to the IT budget and therefore both sides must come together to agree on how to optimize the IT budget.  First and foremost is gaining transparency and understanding of the activities in the IT budgets.  This is critical to minimizing wasteful spending and to optimize the IT activities which support revenue generation.  Business leaders need transparency and understanding of the technology that supports their areas.  IT leaders can help by categorizing their activities.

• 1. Keep the Lights On. These are the activities that are necessary and required in order for the system (I will use the term ‘system’ to broadly describe applications, databases, networks, etc. whether hardware or software) to run and be available in accordance with the users’ expectations (24/7, 8 to 5 Monday through Friday, etc.). It is important that this does not include activities (described below) that enhance or change the system in anyway. This does not include organic growth or other capacity planning. It only keeps the system running in an “as is” state.
• 2. Regulatory and Compliance. Whether required for compliance by your internal compliance team or by an outside regulatory agency, these are the activities that are necessary to update or change the system to comply with these requirements. These changes usually have a deadline associated with them. You can further break this category into group A (external agency) and B (internal agency) if you need to more closely understand the nature of these activities.
• 3. Upgrades and Updates. These changes are strongly recommended by hardware and software vendors for proper maintenance. These are updates to the system that might be necessary because of a product version change or other end of life event that forces the current version to become obsolete or go “out of support”. It does not mean that the system comes to screeching halt, rather it means that without it, the system becomes outdated and either performance is compromised or repairs become more difficult.
• 4. Growth. This category describes the activities needed to keep pace with the organization’s growth.
• 5. System Enhancement. Technology groups tend to enjoy this category the most because of their passion to see and work with the latest and greatest. As a business leader, be careful not to discount the value associated with enhancements as many times there is a valid business case that is simply not articulated in business or revenue generating terms.
• 6. Projects. Project activities could result from business needs or from IT needs, however, they both are grouped in the same category and both need to evaluated against the discretionary budget and the value they bring to the organization.

With a common way to parse and describe the often indescribable IT budget, business and technical leaders can effectively optimize the IT budget, improve their working relationships, and foster greater understanding of each other’s worlds.

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.