In the Field with our Experts

Three-Dimensional Chess

By Stephen Putman, Senior Consultant

I recently read Rob Gonzalez' blog post I've Got a Federated Bridge to Sell You (A Defense of the Warehouse) with great interest - a Semantic Web professional who is defending a technology that could be displaced by semantics! I agree with Mr. Gonzalez that semantically federated databases are not the answer in all business cases. However, traditional data warehouses and data marts are not the best answer in all cases either, and there are also cases where neither technology is the appropriate solution.

The appropriate technological solution for a given business case depends on a great many factors, which I like to call "Three-Dimensional Chess."

An organization needs to consider many factors in choosing the right technology to solve an analytical requirement, including:

• Efficiency/speed of query return - Is the right data stored or accessed in an efficient manner, and can it be accessed quickly and accurately? 
• Currency of data - How current is the data that is available? 
• Flexibility of model - Can the system accept new data inputs of differing structures with a minimum of remodeling and recoding? 
• Implementation cost, including maintenance - How much does it cost to implement and maintain the system? 
• Ease of use by end users - Can the data be accessed and manipulated by end users in familiar tools without damage to the underlying data set? 
• Relative fit to industry and organizational standards - This deals with long-term maintainability of the system, which I addressed in a recent posting – Making It Fit.
• Current staff skillsets/scarcity of resources to implement and maintain - Can your staff implement and maintain the system, or alternately, can you find the necessary resources in the market to do so at a reasonable cost?

Fortunately, new tools and methodologies are constantly being developed that can optimize one or more of these factors, but balancing all of these sometimes mutually exclusive factors is a very difficult job. There are very few system architects who are well versed in many of the applicable systems, so architects tend to advocate the types of systems they are familiar with, bending requirements to fit the characteristics of the system. This causes the undesirable tendency that is represented in the saying, "When all you have is a hammer, everything looks like a nail."

Make sure that your organization is taking all factors into account when deciding how to solve an analytical requirement by developing or attracting people who are skilled at playing “three-dimensional chess.”

 

---

Stephen Putman has over 20 years experience supporting client/server and internet-based operations from small offices to major corporations.  He has extensive experience in a variety of front-end development tools, as well as relational database design and administration, and is extremely effective in project management and leadership roles. He is the co-author of The Data Governance eBook, available at baseline-consulting.com/ebooks.

Do You Know What Your Reports Are Doing?

By Stephen Putman, Senior Consultant

The implementation of a new business intelligence system often requires the replication of existing reports in the new environment. In the process of designing, implementing and testing the new system, issues of data elements not matching existing output invariably come up. Many times, these discrepancies arise from data elements that are extrapolated from seemingly unrelated sources or calculations that are embedded in the reports themselves that often pre-date the tenure of the project team implementing the changes. How can you mitigate these issues in future implementations?

Issues of post-report data manipulation can range from simple - lack of documentation of the existing system - to complex and insidious - "spreadmarts" and stand-alone desktop databases that use the enterprise system for a data source, for example. It is also possible that source systems make changes to existing data and feeds that are not documented or researched by the project team. The result is the same - frustration from the business users and IT group in defining these outliers, not to mention the risk absorbed by the enterprise in using unmanaged data in reports that drive business decisions.

 The actions taken to correct the simple documentation issues center around organizational discipline:

• Establish (or follow) a documentation standard for the entire organization, and stick to it!
• Implement gateways in development of applications and reports that ensure that undocumented objects are not released to production
• Perform periodic audits to ensure compliance

Reining in the other sources of undocumented data is a more complicated task. The data management organization has to walk a fine line between control of the data produced by the organization and curtailing the freedom of end users to respond to changing data requirements in their everyday jobs. The key is communication - the business users need to be encouraged to communicate data requirements into an easy-to-use system and understand the importance of sharing this information with the entire organization. If there is even a hint of disdain or punitive action regarding this communication, it will stop immediately, and these new derivations will remain a mystery until anther system is designed.

The modern information management environment is heading more and more towards transparency and accountability, which is being demanded by both internal and external constituencies. The well-documented reporting system supports this change in attitude to reduce risk in external reporting and increase confidence in the veracity of internal reports, allowing all involved to make better decisions and drive profitability of the business. It is a change whose time has come.

photo by r h via Flickr (Creative Commons License)

---

Stephen Putman has over 20 years experience supporting client/server and internet-based operations from small offices to major corporations.  He has extensive experience in a variety of front-end development tools, as well as relational database design and administration, and is extremely effective in project management and leadership roles. He is the co-author of The Data Governance eBook, available at information-management.com.

Making It Fit

By Stephen Putman, Senior Consultant

I've spent the last eighteen months at clients that have aging technology infrastructures and are oriented to build applications as opposed to buying more integrated software packages. All of these organizations face a decision which is similar to the famed "build vs. buy" decision that is made when implementing a new enterprise computer system - do we acquire new technology to fulfill requirements, or adapt our existing systems to accomplish business goals?

Obviously, there are pros and cons to each approach, and external factors such as enterprise architecture requirements and resource constraints factor into the decision. However, there are considerations independent of those constraints whose answers may guide you to a more effective decision. These considerations are the subject of this article.

Ideally, there would not be a decision to make here at all - your technological investments are well managed, up-to-date, and flexible enough to adapt easily to new requirements. Unfortunately, this is rarely the case in most organizations. Toolsets are cobbled together from developer biases (from previous experience), enterprise standards, or inclusion of OEM packages with larger software packages such as ERP systems or packaged data warehouses. New business requirements often appear that do not fit neatly into this environment, which makes this decision necessary.

Aquire New

The apparent path of least resistance in addressing new business requirements is to purchase specialized packages that solve tactical issues well. This approach has the benefit of being the solution that would most closely fit the requirements at hand. However, the organization runs the risk of gathering a collection of ill-fitting software packages that could have difficulty solving future requirements. The best that can be hoped for in this scenario is that the organization leans toward obtaining tools that are based on a standardized foundation of technology such as Java. This enables future customization if necessary and ensures that there will be resources available to do the future work without substantial retraining.

Modify Existing Tools

The far more common approach to this dilemma is to adapt existing software tools to the new business requirements. The advantage to this approach is that your existing staff is familiar with the toolset and can adapt it to the given application without retraining. The main challenge in this approach is that the organization must weigh the speed of adaptation against the possible inefficiency of the tools in the given scenario and the inherent instability of asking a toolset to do things that it was not designed to do.

The "modify existing" approach has become much more common in the last ten to twenty years because of budgetary constraints imposed upon the departments involved. Unless you work in a technology company in the commercial product development group, your department is likely perceived as a cost center to the overall organization, not a profit center, which means that money spent on your operations is an expense instead of an investment. Therefore, you are asked to cut costs wherever possible, and technical inefficiencies are tolerated to a greater degree. This means that you may not have the opportunity to acquire new technology even if it makes the most sense.

The decision to acquire new technology or extend existing technology to satisfy new business requirements is often a decision between unsatisfactory alternatives. The best way for an organization to make effective decisions given all of the constraints is to base its purchase decisions on standardized software platforms. This way, you have the maximum flexibility when the decision falls to the "modify existing" option.

photo by orijinal via Flickr (Creative Commons License)

---

Stephen Putman has over 20 years experience supporting client/server and internet-based operations from small offices to major corporations.  He has extensive experience in a variety of front-end development tools, as well as relational database design and administration, and is extremely effective in project management and leadership roles. He is the co-author of The Data Governance eBook, available at information-management.com.

I’m All Ears

By Caryn Maresic, Senior Consultant

Most Data Warehouse designs include constructs for Address, Phone, and/or Email for Customers.  Len Silverston came up with what he calls a Universal Data Model that does a very good job of abstracting address, email and phone number data.  I have seen clients use the Contact Point portion of his model as-is and with a few simplifications with great success.  That being said, in the area of Marketing and Sales, the manner in which we reach out to our customers and prospects gets more diverse every day.  Disneyland has just partnered with Verizon so that park guests can get real time information about the park and play Disney games on their phones….and, of course, Disney gets access to more information about its customers!

How does this new and ever changing world of communication change the way we think about and model contact points?  What would my “address” look like if I were near the Haunted Mansion looking for a lunch spot?  Would it be different than if I were at Downtown Disney looking for a cup of coffee?  On Main Street looking for Winnie the Pooh?  In all instances I would be using the same phone, possibly the same IP address, but I would be in different locations which would be important to the marketeers at Disney.

As time goes by (and cell phone GPS systems become more accurate) I suspect that the way we run marketing campaigns to smart phones will be similar to the way in which we use billboards today.  Where the customer is physically located at any given time will be as important as the phone number and/or IP address, thus creating a two dimensional contact point.

Have you come across this issue in your organization?  Have you changed your data model to include two dimensional contact points?  If not, has the use of smart phones changed your data model in other ways?

photo by wrayckage via Flickr (Creative Commons license)

---

Caryn has over 20 years experience in providing high-quality data solutions to clients in the areas of Business Intelligence, Data Warehousing and System Integration.  Caryn has expertise in across industries with an emphasis in Pharmaceutical, Manufacturing, and Insurance.  Prior to joining to Baseline, she ran her own consulting company.

A Data Governance Primer (Part 3 of 3)

By Carol Newcomb, Senior Consultant

Diamond in the Rough: Data Quality

The third part of my summertime primer addresses Data Quality Analysis.  Don’t even start a data quality analysis until you have completed the first two steps of your Root Cause Analysis--investigate & prioritize any potential causative factors, and start your metadata assessment.  Otherwise, you may be misled by your findings.

Data quality is defined as complete and accurate data that is ready for business consumption.  Sources of poor data quality may include lack of data entry rules, unclear data element definitions, inconsistent metadata definitions for field type, format or intent, or breakdowns in data transformation processes as data flow between systems or applications.  Poor data quality results in bad business decisions; it contributes to major problems in using data effectively, and costs companies millions of dollars/year in terms of rework and inefficiency.  Data quality, in combination with robust metadata definitions, is part of the foundation of good data governance.

Data Quality Analysis

A Data Quality Management process should be designed to enable an area to start with a simple approach and over time to mature to one that is more proactive and comprehensive.  Initially, investigation may be focused on single data elements or events.  As patterns, data commonalities and other relationships appear, the data quality management process will grow to support complete business processes.   A mature data quality management process will not just resolve individual issues; it will also track relationships between data elements, ensure that business rules are consistent and generate statistical analyses to monitor previously addressed issues to ensure that data quality is stable and that an early warning system is in place as part of the data governance program.  The goal is to design a data quality management lifecycle, as shown in this diagram:

Initial Data Quality Analysis Process

I. Define data scope

• Determine data elements that are associated with or are direct results of the reported issue
• Check that all metadata definitions are present and current
• Enlist the involvement of the Data SME or Data Stewards
• Identify all source systems where the data originates, is  entered or derived

II. Extract and profile the data

• Extract the relevant data from all key source systems.
• Design the profile.  A profile will consist, at a minimum, of total record counts, min/max values, frequency of unique values, and frequency of invalid values (if defined) for each data element profiled. 
• Profile the data to determine key characteristics that are contributing to the issue, such as:
• 1. Wrong values
  2. Missing values
  3. Corrupt transformation processes
  4. Incorrect business rules
  5. Incorrect usage rules

III. Analyze Data Profile Results

• Summarize the key findings from the profile detail
• Determine what key drivers are contributing to the impact
• Determine accountability for the data quality issue
• Involve other Data Stewards in troubleshooting and designing the data quality solution

IV. Design the Corrective Action Plan

Two types of plans should be developed to address known data quality issues: a corrective action plan to fix the immediate source of the problem identified, and an ongoing monitoring plan, where thresholds have been determined and metrics are routinely collected and reported to data stakeholders.  This monitoring process should be scalable based on the number of data elements being tracked.

1. Corrective Action Plan
2. • Does scope of problem warrant change in metadata definitions, business practices or data entry rules?
   • Does scope of problem warrant a data governance standard?
   • Does the corrective action plan include details on how to fix the source of the problem as well as ways to correct historical data in the system?
3. Preventive Action Plan
4. • This plan will be designed to minimize the probability of data quality issues from recurring
   • Determine ‘early warning triggers’ based on designated thresholds.  These thresholds should reflect the business tolerance for inaccurate data (is 95% acceptable?)
   • If data latency is the source of a data quality issue, then latency thresholds should be included in the monitoring plan
   • Determine how frequently results of the monitoring plan will be reported to data stakeholders or governance oversight committees

So, now that summer is officially here, this wraps up my Data Governance Primer series.  Time for some iced tea and my favorite beach towel.  Come August, these little refreshers might be just the thing!

photo by Swamibu via Flickr (Creative Commons License)

---

Carol Newcomb is a Senior Consultant with Baseline Consulting. She specializes in developing BI and data governance programs to drive competitive advantage and fact-based decision making. Carol has consulted for a variety of health care organizations, including Rush Health Associates, Kaiser Permanente, OSF Healthcare, the Blue Cross Blue Shield Association and more. While working at the Joint Commission and Northwestern Memorial Hospital, she designed and conducted scientific research projects and contributed to statistical analyses.

A Data Governance Primer (Part 1 of 3)

By Carol Newcomb, Senior Consultant

They say that Data Governance is about People, Process and Organization.  Much of the design work in planning for data governance is around people’s roles and responsibilities, then designing the organizational structure that will provide authority for decisions to be made and enforced.  The processes, however, are not new.  They are probably already being practiced within your organization, just in a decentralized, informal way.  In this blog series, I discuss the processes for 1) investigating and isolating the data quality issues—Root Cause Analysis—, 2) starting to collect complete Metadata Definitions, and 3) performing Data Quality Analysis.  Only when your governance group has worked through each step, in order, will you be more likely to design the appropriate solution.

Root Cause Analysis

The process of data governance is fundamentally very simple.

1. Identify the data quality issues to address
2. Prioritize the portfolio of issues to isolate/tackle the most important
3. Perform Root Cause Analysis to determine the true source of the data issue
4. Design the corrective action
5. Formalize the correction through consideration & approval by the Data Governance organization
6. Implement the fix
7. Monitor the results

It seems like when we start to map out the discrete steps involved in the data governance process, much of the work is already being done in informal ways throughout the organization.  What some folks don’t realize is that data governance is often nothing more than formalizing a whole bunch of informal processes that either don’t get communicated, or aren’t accepted as a data standard.

Root Cause Analysis is the process of identifying probable causes of a data issue, and isolating the contributing factors.  In order to resolve any particular issue, root cause analysis involves fact-finding, drilling into details of the problem, talking to the right people, and separating out other associated (but not contributing) factors.

A standard tool for supporting the detailed findings is the Ishikawa Diagram, below.  

To conduct a thorough Root Cause Analysis, use the following checklist:

• Diagnose the problem as if you are a physician or a detective. Consider all possible sources of the symptom. Don’t rule anything out yet!
• Boil the ocean—be exhaustive and creative.
• Don't practice problem solving before collecting all possible causes.
• Practice the “5 Why’s”—don’t stop asking “Why” until you have exhausted every conceivable potential reason.
• Rank the factors if possible.  Identify the Primary causes versus the Secondary or associated factors.
• Rule out each possible factor one at a time.  Justify why (you may need to come back to this later).
• Find all potential business process and data owners to involve them in your understanding of the possible sources of the problem.
• Share the findings with everyone involved in troubleshooting. They could rule out certain factors with their knowledge.
• Test your hypotheses with actual data.   
• Fix the problem and test again.
• Publish/share your findings and fixes.  Communicating your findings may reveal additional factors you hadn’t considered.

After a thorough Root Cause Analysis has been completed, Data Stewards should proceed to Metadata Analysis and Data Quality Analysis.  These two techniques will be discussed in my next blogs.

---

Carol Newcomb is a Senior Consultant with Baseline Consulting. She specializes in developing BI and data governance programs to drive competitive advantage and fact-based decision making. Carol has consulted for a variety of health care organizations, including Rush Health Associates, Kaiser Permanente, OSF Healthcare, the Blue Cross Blue Shield Association and more. While working at the Joint Commission and Northwestern Memorial Hospital, she designed and conducted scientific research projects and contributed to statistical analyses.

IT-Business Alignment: Let The Business Drive

By Caryn Maresic, Senior Consultant

Julia’s parents were planning a vacation.  Her mother thought Pensacola would be a great destination—she’s heard so much about the wildlife, especially the dolphins!  Her father wants to see the National Naval Aviation Museum and the Blue Angels.  Since Julia’s traveled extensively, her parents asked her to make all the arrangements.  While having dinner with them to discuss plans, she jotted down the following notes:

• Location:  Moderately-priced hotel close to water/sights.
• Budget: $3,000 for transportation and accommodations.
• Activities:  Beach and nature activities (Mom), science/historic sights (Dad)
• Duration: 10 days.

Julia felt honored that her parents trusted her to get the job done.  After doing some online research, she made all the reservations and met with her parents to review the reservations.  She eagerly awaited the look on her parents’ faces as they scanned the vacation itinerary and read through the glossy brochures.

“Hawaii?”, they said in unison.  “We didn’t want to go to Hawaii!"

"Honey, we chose Florida because we can drive there.  I don’t want to fly anymore.  Flying is such a pain,” Dad grumbled.

“I appreciate what you’ve done, Julia, but an old friend of mine lives near Pensacola and I was hoping to visit while we were there.” said Mom.

“But, Mom!”, exclaimed Julia, “You said you wanted beaches, dolphins, sunny weather.  Dad, you like science and history—what about Pearl Harbor?  You two can’t go to the gulf coast—what about the oil spill?”

What happened here is typical of what happens to IT projects all the time.  It’s easy to say that we wouldn’t do what Julia did.  Would we?  Don’t we oftentimes:

• Interview the business and record the requirements in an abstract way.
• Believe that the we can deliver something better than what the business asked for.
• Assume that the business lacks the capability to understand the technology.
• Fail to get all of the requirements.  Not exactly our fault, but still a problem.
• Neglect to keep the business involved in the process.

There has been a lot of buzz on IT-Business alignment of late, including this article on some specific companies that are going the extra mile: Beyond Alignment—as well as this one on lack of user involvement: Why IT Projects Fail: Lack of User Involvement.  Most companies aren’t as progressive.  The willingness to work together has to occur at all levels. Only when we let them drive can we deliver, if not what they asked for, then at least something useful.

photo by stevendepolo via Flickr (Creative Commons license)

---

Caryn has over 20 years experience in providing high-quality data solutions to clients in the areas of Business Intelligence, Data Warehousing and System Integration.  Caryn has expertise in across industries with an emphasis in Pharmaceutical, Manufacturing, and Insurance.  Prior to joining to Baseline, she ran her own consulting company.

The “Temporary” Building

By Stephen Putman, Senior Consultant

I was walking my dog on a sunny morning recently when we cut a path through my daughter’s middle school. I saw a group of temporary buildings attached to the main wings of the school, operating as additional classrooms. These new buildings were made to appear to be integrated with the existing classrooms, but it was obvious that they didn’t quite fit.

I thought back to my own years in middle school in the 1970s. My school was a recently-converted elementary school, and there were several temporary buildings constructed to provide facilities appropriate to a middle school, just like at my daughter’s school. I went back to that school a couple of years ago, and those temporary buildings were still there, 35 years later. I thought, “Aren’t these building called temporary for a reason?”

I believe that these buildings are still being used well past their original lives because of short-term, tactical thinking - it’s easier to keep things going as they are than to endure short-term disruption to build more long-lasting, integrated structures. Years of this tactical decision-making extend the lives of these buildings, even though it is likely that it is more expensive to maintain these buildings than the cost of erecting solid and permanent structures.

This reminds me of some data warehouses I’ve seen at our clients. Their enterprise reporting capabilities are built like these temporary buildings, with mismatched parts that are not integrated and often maintained at a higher cost than a solid, foundational system. I have seen many instances of reporting systems that are maintained constantly, manually, and reactively, nursed along over the years in the mistaken belief that maintaining these systems are less costly than building a permanent, integrated system, ignoring the cost and synergy benefits.

Don’t spend your time, effort, and money maintaining temporary structures--they may stay around much longer than you intend, and cost you much more in the long run.

photo by teofilo via Flickr.

---

Stephen Putman has over 20 years experience supporting client/server and internet-based operations from small offices to major corporations.  He has extensive experience in a variety of front-end development tools, as well as relational database design and administration, and is extremely effective in project management and leadership roles.

BI and Data Warehousing, and the Role of Business Analyst

By Steven Bebout, Senior Consultant

When I tell people what I do for a living, their eyes typically glaze over.  I am a business analyst with an area of expertise in the DW/BI warehouse space.  When asked to elaborate, my story changes depending upon the industry, current state of the client, politics, budget, priorities within an organization, the client’s history with past data warehousing efforts, etc…

Fundamental responsibilities include: liaison between the business and technology team.  I gather data analytic specific  business requirements; making sure that the data is there to support the requirements, ensure that the preliminary conceptual data models  validate business scenarios, and work closely with testing teams to make sure that the requirements are met.  Gathering thorough business and data requirements leaves the DW more robust and flexible as users further define their needs (especially reporting needs).

I’d like to provide the analogy of building a foundation for a house; a house needs a foundation to shoulder its considerable weight, provide a flat and level base for construction and separate wood-based materials from contact with the ground, which would otherwise cause rot and allow termite infestation.  This analogy aligns itself well to a data warehousing project.

The business analyst provides the foundation for the data warehousing project.  They shoulder the weight of understanding and identifying data and process deficiencies as you are doing the DW/BI analysis; serving as a business-oriented project resource.  In some instances, they may have a systems orientation but this is not an expectation of the business analyst’s knowledge set.

The business needs of the organization are identified by interviewing the key stakeholders.  You interview IT to determine technical feasibility, not business needs.  IT doesn’t define business needs; they only tell you if it can be done and what it will cost.  You take that information back to the business and let them decide if they want to pay for it. Identifying these business needs helps to develop the design needs of the data warehouse; missing or misinterpreting the needs creates ‘infestations’ as described in the housing analogy. 

It has been my experience that the business analyst is the right hand and often assists the project manager throughout the project.  Knowing the foundation of the project and utilizing their client facing skills provides the project manager confidence that in their absence, the business analyst can attend meetings and speak knowledgably on their behalf.

The most successful DW/BI projects I have been involved in are ones where the business analyst is gleaning the user's wants and needs for the business requirements and the data architect/modeler is analyzing the data sources, underlying processes and data quality aspects.  Together they work to construct a business-driven and data-driven conceptual and logical model (and also a dimensional and star-schema model if appropriate).  A broader combination of efforts includes working with the development team to discern the functional and non-functional requirements for the reporting or analytic deliverables and the physical model (normalized or multi-dimensional as appropriate).

I realize that some people are capable of fulfilling both roles (business analyst and data modeler), and certainly on smaller project might be called upon to perform both roles. However, due to the business complexity, the need for quick success, the economic pressures, etc., I don't personally subscribe to the ‘jack of all trades’ model.

Certainly being knowledgeable in both areas makes sense, but realistically I think it is more prudent to focus on the task at hand and collaborate together.  What is your opinion of a business analyst fulfilling both roles?  Do you see fulfilling both roles as a value-add or as a potential pitfall in resourcing?

photo by Martin Pettitt (via Flickr)

---

Steve Bebout is a consultant with over 15 years of experience in information technology in the areas of application development, business requirements, data analysis, and project management.  He has experience in the Communications Media and Entertainment, Financial Services, Life Sciences, and Insurance vertical markets; spending the majority of his efforts on customer data integration initiatives. 

The Metadata ROI Series: Episode 1: Business Analysis

By Stephen Putman, Senior Consultant

This posting is the first in a series discussing various aspects of the financial justification of a metadata management system implementation that are not obvious in many existing analyses. Today, we will discuss the time and effort saved by Information Technology business analysts in system implementation projects.

In a database implementation project, one of the first activities performed is the gathering of business requirements. These requirements are gathered from business users mainly by interviews and document inspection. The business analysts (and data modelers) take this information and produce documentation describing these requirements, and often perform data mapping between systems when data movement is required.

A basic function of a metadata management system is to describe data elements within computer systems and record attributes of these elements, such as the resident table(s), data types, business rules, and so on. A metadata management system makes it easy for the business analyst to gather relevant information about the existing data elements involved in the data movement in the system, and aids in the design of the data store for the new system by facilitating the data mapping exercise. These two simple uses of the repository save a tremendous amount of time and effort by the analysts in these activities.

It is a simple matter to quantify the cost savings of maintaining a metadata management system for business analysis activities by determining the time spent by staff on collecting and transcribing source data element definitions, subtracting the (very small) time spent extracting the same information from the metadata management system, and multiplying the result by the salaries of the business analysts involved in the project. This result is placed in the “return” bucket of the Return on Investment calculation. This savings is also something that continues to pay dividends over time when more projects utilize the metadata repository in this way.

This example shows that metadata management systems positively affect several areas or your IT organization that are not immediately apparent. I will be detailing more of these functions over the next few months.

---

Stephen Putman has over 20 years experience supporting client/server and internet-based operations from small offices to major corporations.  He has extensive experience in a variety of front-end development tools, as well as relational database design and administration, and is extremely effective in project management and leadership roles.