 | Level: Intermediate Leon Gong (leongong@us.ibm.com), Software Engineer, IBM
Mike Olivas (molivas@us.ibm.com), Senior IT Specialist, IBM
Christine Posluszny (cpos@us.ibm.com), Software Engineer, IBM
Donna Venditti (donnav@us.ibm.com), Project Leader, IBM
George McMillan (gmcmillan@us.ibm.com), Software Engineer, IBM
16 Jun 2005 Take a flexible and effective approach to plan, design, and implement a basic data warehouse solution based on IBM™DB2® Data Warehouse Edition. Part 1 of this article series focuses on the customer engagement process and on planning a data warehouse project.
Introduction
Business Intelligence has evolved to include more and more data analytic technologies. No matter which data analysis approach you take, the data warehouse remains a vital foundation for leveraging information assets. This article series will help you deliver the kind of data warehouse infrastructure that is essential to on-demand Business Intelligence, using IBM DB2 Data Warehouse Edition (DB2 DWE). This article focuses on data warehouse planning, which includes the customer engagement process, business discovery, project proposal, and project plans.
Target audience
This article is written for IT professionals who want to know how to deliver a data warehouse solution. It assumes that you are already familiar with system and database concepts. There are many topics not covered here that are also fundamental in delivering a good data warehouse solution, including system and database design, administration, performance tuning, and others. This article only focuses on issues closely related to data warehousing.
What is Business Intelligence?
Business Intelligence (BI) is the gathering and analysis of vast amounts of data in order to gain insights that drive strategic and tactical business decisions. BI is the collection of the processes and technologies which transform data into information. It encompasses a broad category of technologies, including data warehousing, multidimensional analysis or online analytical processing (OLAP), data mining, and data visualization, as well as simple queries and many types of analytical tools for reporting. These technologies allow business users to gather, store, access, and analyze data to improve the business decision-making capabilities.
Figure 1. What is Business Intelligence?
What is a data warehouse?
A data warehouse is a centralized repository containing comprehensive detailed and summary data that provides a complete view of customers, suppliers, business processes, and transactions, from a historical perspective with little volatility.
A data mart, on the other hand, contains a subset of the data stored in the data warehouse that is of interest to a specific business community, department, or set of users (for example: marketing promotions, finance, or account collections).
It is important to realize that a data mart is defined by the functional scope of its users, and not by the size of the data mart database. In a well structured BI system, the data warehouse serves as a single source for multiple data marts.
What is data warehousing?
Data warehousing is the design and implementation of processes and tools to manage and deliver complete, timely, accurate, and understandable information for decision making. It includes all the activities that make it possible for an organization to create, manage, and maintain a data warehouse or data mart. Data warehousing deals with managing the development, implementation, and operation of a data warehouse or data mart. It includes metadata management, data acquisition, data cleansing, data integration, storage management, data distribution, data archiving, operational reporting, analytical reporting, security management, backup and recovery planning, and more.
The following sections provide an introduction to data warehousing (excluding reporting and analysis). Specifically, they focus on preparing data for analysis -- the task that usually accounts for 80 percent of the schedule for most data warehouse projects.
Why IBM DB2 Data Warehouse Edition?
IBM DB2 DWE is a powerful and complete Business Intelligence infrastructure product that includes DB2, integrated OLAP, advanced data mining, data Extraction, Transformation, and Loading (ETL), reporting tools, and more. DB2 DWE works with and enhances the performance of advanced desktop OLAP tools, such as DB2 OLAP Server and others from IBM partners.
DB2 DWE is one of the most cost-effective data warehouse tools. According to a research report by Market Magic Ltd in 2004 (see Resources), the Probable Cost of Ownership™ (PCO) of DB2 DWE over five years for data warehouse implementation is lower than that of Oracle and NCR Teradata.
The ability to scale predictably and without limits is a key criterion for a Business Intelligence platform. DB2 meets this need through its unique implementation of the shared-nothing architecture. Scalability applies to both large and small databases.
Scalability and price are important, but those alone do not solve the challenges of building a BI platform. DB2 DWE completes the picture by delivering key analytic and mining technologies as well. DB2 also comes fully integrated with DB2 Cube Views for OLAP applications, Intelligent Miner Scoring for real-time data mining inside the database, and innovations like spatial extenders and XML querying deeply embedded inside DB2, ensuring seamless integration and optimized performance.
Customer engagement process
The customer engagement process of a data warehouse solution is similar to that of other IT solutions in some ways. However, the data warehouse solution has some important differences, including: a strong orientation toward business data, multi-level iteration of the process, and more end-user involvement.
The following diagram shows the main interactions that you, as the provider of a data warehouse solution, will have with your customer over the course of a successful project.
Figure 2. Data warehouse solution customer engagement process
- Solution start up: In this initial customer engagement step, you and your customer decide to start a data warehouse project, and begin setting up an agreement. Because it is a generic step for all kinds of projects, it is not discussed in detail in this guide.
- Business discovery: This is the process of understanding the gap between current and expected business data analysis requirements. It includes gathering and documenting business requirements, understanding the customer environment, and completing gap analysis. (See the following section for details.)
- Solution proposal: Based on the customer requirements, you create proposals for a data warehousing project or solution.
- Solution planning: In this step, you plan the solution and identify the data warehouse infrastructure, personnel, and resources needed.
- Warehouse conceptual modeling: Warehouse high-level design includes warehouse architecture and implementation choices, and conceptual data modeling, which capture all business subject areas defined in the business requirements.
- Warehouse phase design: Warehouse phase design includes both logical and physical data modeling, which captures the business requirements in a much more detailed level, but only covers the subject areas in the current project iteration. This step also includes ETL process design.
- Solution implementation cycle: The data warehouse implementation includes the target repository and the data mart database, as well as ETL process implementation.
- Solution deployment: The new data warehouse solution moves into a production environment.
This data warehouse customer engagement process is based on the bottom-up (or phased) data warehouse implementation approach. After you deploy the data warehouse solution, the project may start on new logical and physical data modeling for other business subject areas with regards to the current business requirements, or if there are new business requirements, restart the business discovery phase.
Business discovery
The business discovery process includes three tasks: gather and document business requirements, understand your customer's business environment, and perform gap analysis. These three tasks can overlap, and you will often perform some of these tasks at the same time. For example, one part of understanding business requirements is to investigate your customer?s business data sources, which covers all three of the business discovery tasks. It is important for a solution provider to understand the goals of every task before beginning the business discovery process.
The purpose of gap analysis is to understand your customer's business pains and needs, and to estimate the resources that are needed to fill the gap between their current business status and their business requirements.
Figure 3. Business discovery process
Gather and document business requirements
During this task you should be able to uncover and understand your customer?s business pains, identify and prioritize the business requirements, and focus on the business subject areas of interest.
In a perfect world, you may have a complete set of written business requirements for a data warehouse project at the beginning of the customer engagement. In the real business world, especially in mid-market companies, the initial business requirements are usually not complete; often the initial contact may have consisted of a phone call, e-mail, or casual conversation. It is important to follow up any initial meeting to completely identify all business requirements before you invest too much time and resources into the project.
Gathering complete business requirements is not a trivial task. It requires active communication with your customers. The best fit for this job is an experienced business analyst with strong business and people skills, as well as reasonable knowledge of data warehousing and data modeling.
Determine end-user requirements
During the requirement-gathering process, you collect and document end-user requirements. You will often study how end users are involved in business processes and information analysis activities. Since these end users do not necessarily understand data warehouse concepts, you should ask questions that allow you to gain an understanding of specific business problems. At this stage, it is common to find that end-user requirements are documented rather informally, and they are not represented in detailed data structure. When gathering end-user requirements, you might interview end users, study existing documents and reports, and monitor ongoing information analysis activities. Experience with business process engineering and information analysis can be very helpful.
End-user requirements can be classified into four categories:
- Business objectives are high-level expressions of the goals of information analysis, in business terms. A given data warehouse project can have one or more business objectives. For example, a business objective could be: "The data warehouse has to support the analysis of operational costs, and the analysis of profit from the sale of products."
The set of combined business objectives in a data warehouse project can help determine the project scope. They can also help you to identify information subject areas involved in the project, and to identify (usually high-level) measures of the business processes that the end user is analyzing.
- Business queries represent the queries, hypotheses, and analytical questions that end users ask and try to resolve in the course of their daily information analysis activities. Just as with business objectives, business queries are expressed in business terms. You should expect that they are usually not precisely formulated. They are not expressed in terms of SQL. Some examples of frequently encountered categories of business queries include:
- Existence-checking queries, such as "Has a given product been sold to a particular customer?"
- Item-comparison queries, such as "Compare the value of purchases of two customers over the last six months," or "Compare the number of items sold for a given product category, per store, and per week."
- Trend-analysis queries, such as "What is the sales growth for a given set of products over the last 12 months?"
- Queries to analyze ratios, rankings, and clusters, such as "Rank our best customers in terms of dollar sales over the last year."
- Statistical analysis queries, such as "Calculate the average item sales per product category, per sales region."
- Data analysis scenarios are a good way of adding substance to the set of requirements that you are capturing and analyzing. For example, some business requirements are generated by analyzing existing report query workflows and interpreting current business data analytic structures.
- Existing data models may be available and could be used to further specify or support end-user requirements. You can collect the data models by re-engineering and integrating source data models.
The collection of end-user requirements covers many areas, and many factors can affect the results. These factors might include the end users? business knowledge, how well they can express themselves, or how much time they have for the interview. User requirements also change over time, and what is true one day might no longer be valid the next. How do you know when you have successfully identified the users? requirements? There is no definitive test, but if your requirements address the following questions, you probably have enough information to begin data modeling:
- Who is of interest to the user? Consider individuals, groups, and organizations.
- What business processes and functions are the end users trying to analyze?
- Why does the user need the data?
- When (for what point in time) does the data need to be recorded?
- Where (geographically, organizationally) do relevant processes occur?
- How can you measure the performance or state of the business processes and functions?
Determine functional requirements
While the end-user requirements help you understand current business processes and business pains, the functional requirements help you understand the scale of the services that your customer expects from a data warehouse solution. The questions to ask are based on your data warehouse knowledge, your evaluation, and your understanding of end-user requirements. The functional requirements information usually comes from key business contacts, business managers, IT professionals, and the potential end users. The functional requirements help you to set the overall project scale and goals. Ask the following questions:
- What new information analysis capabilities do you need to improve your business? Give a detailed definition of the reports that you expect to build based on the data warehouse.
- If there is an existing data analysis process, what problems have you encountered with it?
- How many potential users of the new data warehouse solution are there, and where are they located?
- How often do the business reports need to be rebuilt?
- Who will be involved on the project from the client side, and what are their responsibilities?
- What is the budget of the project (if that information is available)?
- What is the target date for the project completion?
- If there are business specific aggregation measures, what are the definitions of those measures?
- What kind of security configuration is needed for the data warehouse?
Understand the customer?s environment
Understanding the customer's environment begins as soon as you start gathering and documenting business requirements. These tasks will continue during the whole project. It is important to understand the customer's environment at the early stages of the project, in order to avoid misunderstandings and unwelcome surprises in the data warehouse projects. Many business and technical assumptions will be based on the result of early investigation of the customer?s environment.
Understand the customer business environment
It is difficult to predict the knowledge you need in order to fully understand the customer's business environment, because every business is unique. However, there are several things you definitely need to know for a successful customer engagement. They include, but are not limited to:
- Who is the decision maker for the project?
- Who is the key contact person for the project?
- What kind of business problems need to be solved?
- Who are the end users? The end users might not be the decision makers, but they provide valuable information about the usability of the data warehouse.
- What special business knowledge do you need?
- Does your customer have an IT staff? If so, how much support can you get from them?
Understand the information infrastructure environment
The customer's network environment can be simple or complex. You may not need to understand everything about their network, but you need to document anything related to the data warehouse production environment in order to design and configure the data warehouse. Here are some things that you should know:
- What kind of network connectivity and protocols are used in the production environment?
- What is the average and peak throughput of the network traffic? When are the rush and peak hours?
- How many end users does the data warehouse need to support? What operating systems and reporting applications does your customer plan to use?
- Where are the end users located (on the LAN, across the public Internet or a WAN, over a VPN, or some combination of these)?
Understand the data environment
Understanding the customer?s data environment is one of the most important tasks in a data warehouse project. It is the basis for:
- Constructing a realistic project proposal and contract.
- Designing and implementing data acquisition.
- Designing the data warehouse and data mart.
- Designing data verification and cleaning.
Assign this task to experienced data warehouse professionals who understand business analysis, data analysis, and modeling. They need to work closely with your customer?s IT personnel and end users.
To identify the data sources (both internal and external to the business) that will support the warehouse data models and business requirements, you need to document all the data sources. Describe their location, systems, access approaches, source data traffic and update frequency, data security, and data quality.
Data quality is one of the important issues in identifying data sources. Determine not only whether there is business data available, but also whether the data quality of all data sources is high enough to support the business requirements. If there are any data quality problems, both you and your customer need to know as soon as possible.
Data problems may have existed in the customer?s operational data sources for years. In many situations, problems are uncovered in early analysis of source data, or later in the design and implementation of a data transformation process. Make sure to inform your customer so that they can prepare a plan for handling them.
Checking the data quality is not a trivial job; it requires knowledge of both data modeling and the business domain. Most likely, you will need to involve some end users in this task. In some cases, you may not have access to sensitive business data. If this is the case, you should try to get a random sample of the business data and allow your customer to change some data values without affecting data quality.
You need to know as much as possible about the data related to the project. Here are the questions you need to answer in detail (not just at a high level):
- How many data sources are related to the project, and where are they located?
- Will the data warehouse have direct access to the data sources? What kind of data connection is supported?
- Will the data warehouse need any data from outside of the customer?s intranet? How accessible is that data?
- How much new data is generated every day in all the data sources?
- What is the expected frequency of the data updates in the data warehouse?
- Is there any shared data? If yes, which one is the master data source?
- How good is the data quality? If possible, you should examine all data fields available.
- If there is any missing data or dirty data, can your customer correct this in the data sources?
- Can the customer guarantee the data quality of the corrected data fields in the future? If not, who will be responsible for the data cleaning?
- If the missing data or dirty data cannot be corrected in the customer?s data sources, what business rules will be used to correct the data?
Gap analysis
After collecting business requirements and researching the business and data environment, you can perform gap analysis. Gap analysis will examine the information you have, and determine what resources and efforts are needed to satisfy your customer's demands. The purposes of the gap analysis are:
- Understand your customer?s business pains.
- Understand the subject areas of your customer?s problems.
- Give the customer an estimate of the resources or support that they will need to provide, and the development effort required on your part to deliver the solution according to your customer's needs.
- Help identify the technology and tools for the project.
The gap analysis is important, because it is the basis for your data warehouse project proposal and design.
Requirements analysis
Depending on how much time and resources you have, you may decide to keep the requirements analysis on the business level. This means that you will generate complete reports of your understanding of your customer's business pains, business subject areas, report definitions, and performance measures.
Using the requirements analysis techniques, you can build an initial warehouse data model which represents the end-user requirements that you have captured informally. The requirements analysis produces a schematic representation of a model that information analysts can interpret directly. The results of the requirements analysis will be the primary input for data warehouse modeling, after they have passed the requirements validation phase.
Identify business pains
When you have a complete set of project business requirements, the business pains associated with the project should be easy to identify. You might have to go back to your customer and ask more questions in order to discover and prioritize all of their business pains. In a data warehouse project, you usually divide the business pains by department, by business questions that need to be answered, and by the urgency of business problems. In the process of identifying business pains, you could uncover potential new projects, so be aware of any new opportunities.
Identify business subject areas
Subject areas are roughly classified by the topics of interest to the business. To extract a list of potential subject areas, you should first consider your customer?s business interests (for example: customers, profit, sales, organizations, or products). To help determine the subject areas, consider the questions "when, where, who, what, why, and how" in relation to your business interests. For example, potential answers to the "who" question could include customer, employee, manager, supplier, business partner, and competitor. After you have identified a list of subject area candidates, you can decompose, rearrange, select, and redefine them more clearly, resulting in a list of subject areas that best represent your customer's organization. Make a hierarchy or other grouping of the subject areas, to provide a clear definition of what they are and how they relate to each other.
Once you have developed a list of subject areas, you need to define the business relationships between them. The relationships are good starting points for determining the dimensions that might be used in a dimensional data warehouse model, because a subject area is a perspective of the business about which you are interested. It is important to prioritize the subject areas according to your client?s business pains, and base your project proposal on these priorities.
Identify gaps
Based on the results of the business requirement analysis and your understanding of the business environment, you should be able to identify the gaps between what your customer's business has today and what they expect from the data warehouse project.
Data gap
Data is undoubtedly the primary element in a data warehouse project. The first question to answer in your gap analysis is whether the available business data supports the business requirements. Pay special attention to the following areas:
- Is there enough data to meet the business goals of the project? If not, can external data sources be acquired to fill the gap?
- Does the business data quality meet the business' requirements? If not, can it be cleaned enough to meet the stated requirements?
Although it is the customer's responsibility to provide quality data, this is an opportunity to provide additional services to the customer.
Infrastructure gap
Evaluate possible improvements to your customer's network, hardware, software, existing applications, and so on. Pay special attention to the following areas:
- Are the server system and network robust enough to handle the expected warehouse data flow?
- If there are multiple data sources in multiple networks and locations, what types of networks are they? How much data can be exchanged between local networks?
- How accessible are the data sources? If you cannot access a data source directly, what level of IT support will you need from your customer to get the data?
- Does your customer need to have new servers for the data warehouse? If yes, what are the server specifications?
- What kind of data management and data analytics tools are already available in-house? What kind of data analysis service do these tools provide?
Resource gap
Determining the resource gap includes evaluating personnel, skills, domain knowledge, schedules, and budgets. Pay special attention to the following areas:
- Can the customer provide the kind of skills and personnel hours that will be needed to support the project?
- Is your customer?s project budget big enough to cover the complete set of business requirements? If not, which subject areas are most important to cover under the current budget?
Project proposal
All the work you have done up to this point has laid the foundation for your project proposal. At a minimum, a data warehouse project proposal should include the following information:
- Your understanding of the customer?s business requirements.
- Your understanding of the customer?s business pains.
- Your understanding of the customer?s information infrastructure and data environment.
- The solution scope.
- The subject areas of your customer's business problems.
- The business and technical approaches that you use as a solution provider.
- The business and technical assumptions that apply to this project.
- The definition of the project's final deliverables.
If your customer does have some IT professionals who understand data modeling, it would be a good idea to include your initial data mart models in your proposal, to demonstrate how you captured the business requirements.
The complete project proposal is also the basis for the final project contract with your customer. It is critical that you include all necessary business and technical assumptions in the project proposal and contract, so that both sides have a good understanding of what to expect from the project. Any changes to the project assumptions will most likely affect the project schedule and budget; making the customer aware of this reality and stating it explicitly will save a lot of trouble later.
The proposal should include the following project assumptions.
Business assumptions
- What level of your customer?s business knowledge support is needed for the project?
- What level of your customer?s business administration support is needed for the project?
- What level of IT professional support is needed for the project?
- What subject areas are covered in this project, and what are the expected project deliverables?
Technical assumptions
- What data needs to be transferred into the data warehouse?
- How often does the data warehouse need to be updated?
- If there is shared data in multiple data sources, which one is the master data source?
- If there is no master data source, what are the data integration business rules for the shared data?
- If there is missing or dirty data, how will you proceed? The proposal should include detailed written business rules for fixing the data. Your customer should fix missing data in their data source, but they might ask for help. The rule of thumb is that you should not change any customer data, but make your customer's data better.
- What are the business definitions of all data aggregation in the data warehouse? Your customer needs to provide this information. Make sure to specify a due date.
Technology briefing
In the project proposal, you should always describe what technologies you plan to use in your solution. If there is a project proposal presentation, make sure you plan a brief technology demonstration for your customer. It will be very helpful if your customer can see what they are going to get at the end of the project.
Develop the project plan
After the customer signs the solution proposal, the next step is to create a solid project plan that covers as many project details as possible. This plan should clearly document all expectations from both sides, so the customer knows what to expect from you and what you need from them. It is a good idea to involve your customer in developing the project plan as much as you can, because the plan is not really a plan without your customer?s understanding and support. The project plan should contain the elements described below.
Project scope
A data warehouse project plan shares many things with a typical IT project plan. However, a data warehouse project has several unique characteristics:
- Data warehouse objectives are typically defined in general statements. It is important that the requirements for data warehouse development not be too specific. If they are too specific, they may influence the way the data warehouse is designed, to the point of excluding factors that seem irrelevant but may be key to the analysis being conducted.
- One of the main reasons for defining the scope of a project is to prevent constant change throughout the lifecycle as new requirements arise. In data warehousing, defining the scope requires special care. It is still true that you want to prevent your target from constantly changing as new requirements arise. However, two keys to a valuable data warehouse are its flexibility and its ability to handle queries that are unknown at design time. Therefore, when you define the scope, it is essential to recognize that the delivered data warehouse will likely be somewhat broader than indicated by the initial requirements.
- Because of the iterative nature of a data warehouse project, the project scope may only cover the most important or urgent subject areas. However, keep in mind that high-level data warehouse design should include all business subject areas.
- The primary purpose of a data warehouse is for data analysis -- not to mix operational objectives with the data warehouse?s informational objectives.
 |
Infrastructure plan
The data warehouse infrastructure plan describes the software, hardware, data network, and other elements that will support the data warehouse. The infrastructure plan is based on the results of the gap analysis and on the project budget.
Personnel Plan
As soon as the customer approves the project proposal, assemble the entire project team that have been selected for the solution. The skills and personnel plan should include the following details:
- A staffing plan that describes the required skills, detailed responsibilities, and schedules for each team member. There should always be a backup for the key team member.
- An official definition of exceptions, such as changes in project scope or in the project team members.
A data warehouse team should include:
- A project manager, who is responsible for managing and coordinating the solution engagement between you and the customer.
- Domain experts, who provide business domain knowledge for the data warehouse design.
- End users, who are responsible for testing and verifying the warehouse design and implementations.
- A data warehouse architect, who is the key person in data discovery and data warehouse design. It is important to have at least one experienced data warehouse architect involved in a successful data warehouse project. This person usually comes from the warehouse solution provider side.
- A data modeler, who is responsible for both logical and physical warehouse data modeling.
- An ETL developer, who is responsible for ETL design and development.
This is a list of roles; one person can have multiple roles in a data warehouse project. For example, the data warehouse architect and data modeler can be the same person, and the domain experts and end users can be the same group of people.
Design, development Plan
Develop a comprehensive plan for the design, development, and testing of the warehouse solution, according to available skills and experience. All the technical members should be involved in creating this part of the project plan, because only they know what it will take to complete the project. The plan should include:
- A comprehensive list of required hardware, software, and documents
- A detailed list of deliverables the customer will provide (such as organization charts, data, formats, and so on) at different stages or timeframes of the project
- A comprehensive schedule for project design, development, and testing activities
- A detailed list of deliverables you will provide (including documentation, training material, and the solution itself) at different stages or timeframes of the project
- A comprehensive list of project dependencies, assumptions, and risks, with backup plans.
Project checkpoints plan
You and your customer should work together on a project checkpoints plan. Some customers actually use this plan to sign off on the project step by step. This plan should include:
- A comprehensive schedule including major checkpoints for both you and the customer.
- A comprehensive list of project deliverables for each checkpoint.
Deployment and user acceptance test plan
Before deploying all or part of the solution deliverables to the customer's production environment, you should perform a User Acceptance Test (UAT). UAT is a very formal end-user testing procedure; it is your customer's formal approval of your project deliverables. The UAT process might require a significant amount of time from your customer's end users, because you might need to educate them first before they can start UAT. This plan should include:
- The final deliverables of the project and their deployment schedules.
- Plans for educating end users about the solution.
- A UAT schedule.
Customer education plan
Customer education is part of every stage of the data warehouse project. Involving your customer's end users in the solution development process is important, because your customer may correct mistakes at an earlier stage, and the customer also learns a great deal about how to use the solution. The customer education plan should include:
- A list of end users assigned to the project and their project schedules.
- A list of major checkpoint project deliverables (including user documents) and schedules.
- A schedule of formal user education presentations.
Financial and technical risk assessment
A data warehousing project is a high-risk business if there are not enough experienced and skilled persons involved. Have experienced colleagues in your own organization review the data warehouse project plan to make sure:
- The project technical risks are reasonably low.
- The project schedule is practical.
- The project will be profitable.
After this assessment, review the project plan with your customer and establish a mutually agreeable project plan.
Coming next
Stay tuned for the next article in this series, which covers the data warehouse design and implementation stages.
Resources
About the authors | 
| | Leon Gong is a solution architect working in the IBM Solution Builder Express team. He has been working to help enable business partners to create solutions in different industries and solution areas including, but not limited to, business intelligence, infrastructure, and e-commerce. He has DB2 certifications in both application development and administration. You can reach him at leongong@us.ibm.com. |
| 
| | Mike Olivas is an architect working in the IBM Solutions Builder Express team. Lately, he has been working to help enable business partners to create solutions in different industries and solution areas including but not limited to business intelligence, infrastructure, and workplace services. You can reach him at molivas@us.ibm.com. |
| 
| | Christine Posluszny is a solutions developer in IBM Solution Builder Express Portfolio. She has 6 years of experience developing Java and SQL applications leveraging DB2. Recently, she has developed integrated solutions for IBM Mid-Market Business Partners. She is a Sun certified Java Programmer. You can reach her at cpos@us.ibm.com. |
| 
| | Donna Venditti is a project lead in Solutions Builder Express. For the last 6 years, she has delivered both industry and cross-industry starting point solutions for IBM Mid-Market Business Partners. Her focus has been on e-commerce and business intelligence solutions for the retail industry. You can reach her at donnav@us.ibm.com. |
| 
| | George McMillan is an architect working in the IBM Solutions Builder Express team. Most recently, he has been working with business partners and SBE architects developing consultant's tooling, and as methodologist developing method strategies for the partner channel. His work includes creating solutions for business partners in different industries and solution areas. He acts as technical lead in the areas of collaboration and content management, and participates on teams developing business intelligence and infrastructure solutions. You can reach him at gmcmillan@us.ibm.com. |
Rate this page
| |
