In the Field with our Experts

Data Architect – Who is right for the job?

by Caryn Maresic, Senior Consultant

The Data Architect is the core of any BI team.  It is important to choose a person with the right skill set.  As I tried to put together a list of skills I looked to IT Toolbox and Database Answers for help, but my mind wandered a bit.  System Construction. Data Architect. Data Warehouse. Software Factory.  We like to portray what we do in terms of construction and/or manufacturing.  A recent client bemoaned her departments inability to move from “building custom cars” to “an assembly line”.  Comparing ourselves to these burly industries might make us feel strong, but it does it accurately represent what we aspire to be?

What is a Data Architect?  What should they know how to do?   I borrowed the following description from this article. Before you click, read on and see if you can guess what this is really describing.  I think it is a great description for a Data Architect:

A Data Architect is qualified by education, experience, and imagination to enhance the function and quality of systems. The purpose of this pursuit is to improve the quality of life, increase productivity, and protect the health, security, and welfare of the business.

The best Data Architects are capable of analyzing a client's needs, goals, safety and business requirements and integrating this information into a design that is both pleasing to the eye and functional. They will work with the client closely to develop preliminary design concepts that meet their aesthetic, functional, and economic needs while maintaining adherence to standards.

In essence, the best Data Architects are part detective, part artist, and part psychologist and they use these skill sets to create systems that fit a client's tastes and needs with their budget in mind.

Doesn’t that sound like a great job?  Sign me up!  What this is actually describing is an interior designer.  While I doubt that HGTV has any plans to showcase the next dashboard you build, we are indeed closer to Designing Women than Rosie the Riveter!  Stay tuned for future posts on the talents of a good Data Design Star.

photo by Annahape Gallery 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.

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.

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.

Consulting Terms of Engagement: a Readiness Checklist

By Carol Newcomb, Senior Consultant

Having worked at least half of my professional life either with consultants or as a consultant myself, I need to offer some practical advice on increasing the probability of success on a consulting engagement.

Remember, a consultant is just another tool in your management toolbox that provides either the leverage (expertise/experience) or the hard skills that you and your staff are missing today.

There are three main reasons to hire consultants:  1) you want coaching from expert advisors to mentor your existing team and provide tactical advice; 2) you don’t have the skill-sets that you need (ETL programmers, software/hardware experts, etc.); or 3) to provide frameworks and processes to build and sustain ongoing programs (like business intelligence or data governance).

Regardless of the type of consulting engagement, your staff need to be on board with the presence of consultants in their midst.  Ask yourself, as the sponsor, some basic questions:

• Have you explained to your team what the purpose of the consulting engagement is intended to achieve and their role in making it successful?
• Are you as a sponsor willing and able to provide authority for the consultants on the ground?
• Are you willing to spend time with your team and the consultants in the same room, to work out issues, questions, strategy and tactics as they evolve over time?  Don’t think you can just punt and run.
• Do you have committed resources on your team to help with knowledge transfer?  This is not an “all other duties as assigned” task for your staff.
• If consultants will replace or supplement existing staff, is your staff aware and comfortable with this?  This will inevitably become a problem if the expectations are not managed upfront.
• Are IT and Business ready to start working together?
• Do you have true business users and are they ‘on board’ with your project?
• Is there a way to prioritize issues as they come up?  One thing all consulting engagements do is bring to light an unsightly set of issues that become obstacles to progress.
• Can you be honest about your culture? Are their repeated patterns or behaviors that could sabotage a key project?
• Can you comfortably “park” issues that are not showstoppers in order to move ahead despite them?

There are probably many more items I could include on this “preparedness checklist.”  The point is that consultants can often be perceived as disrupting the natural order of things.  Either you, as their sponsor, will need to introduce them and guide them through the organization to ensure they are effective, or you need to clearly delegate to your staff what the expectations are for them to do the same.  If technical knowledge transfer needs to occur, don’t just assume it will happen.  I have seen too many consultants spend the first few weeks twiddling their thumbs either because they don’t have access to key systems, or they don’t understand the environment and haven’t been provided any documentation to work with in the meantime.  How much time will you allow for consultants to become proficient?

If the consulting engagement is to collect facts, conduct interviews, summarize findings, provide best practices, roadmaps or assessments then make sure they have a political lay-of-the-land upfront.  Otherwise, they will attend meetings they have no context for, they will assume things that may be incorrect, and they will be off-target in their recommendations. Also, many consulting firms sell their methodologies as separate and packaged products. If you expect your consulting firm to transfer its intellectual property as part of the engagement then your consulting contract should stipulate that. If you have secured the funding to bring consultants into your organization, you need to ensure that the project is a win-win.  The risks to you are probably larger than to the consultant group, because at the end of their engagement, they go away.  A good consulting firm will have ensured knowledge transfer along the way, but your staff carries some of the responsibility for that, too. 

If you’re considering or starting a consultant engagement, here are a few things to consider:

• Is your department/division receptive to advice or change?
• Are department heads, directors and managers on board with the engagement?
• If ‘best practices’ are recommended, does the department have the appropriate technical tools and agility to put them into practice?
• Have you done everything within your control to ensure the success of this engagement?

If the answer to any of the above is NO, then reconsider your readiness, regroup with your staff, and discuss alternative strategies with the consulting group you are working with.

If you have an opportunity to change and improve your department, leverage the effort to instill that change.   You may not get more than one chance.

photo by mykpwedding 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.

The Value of a BI Scorecard Assessment

By Robert Stone, Senior Consultant

A beacon in the night. A BI Scorecard is just that. And more.

Your team works hard. You have meetings. You go to the trade shows. Yet your business intelligence is not driving the business as it should. It’s lagging and it’s telling you what the history of the business was—and not guiding the business to better decisions. After many years of development and a lot of investment, you have the same reports you had five years ago, just nicer looking. What you need is a beacon to guide you, a scorecard on your business intelligence environment that points you to key leverage points that may be limiting the flexibility of your business intelligence.

Awhile back, I was part of a team to do a BI Scorecard for an insurance company. Business was dissatisfied with the quality and agility of the business analysis reporting. IT was swamped with report requests and changes to the data warehouse and had little bandwidth to step back and take a fresh look at their BI environment. It’s the ol’ can’t see the forest for the trees adage. Nobody’s to blame, but it happens all the time and it often takes an outsider to see the root issues.

Business and IT both agreed to bring us in to interview business users and IT staff. We focused on six core areas and did a comprehensive set of interviews—plus we did an analysis of their documentation and reports to verify that what we were told matched their actions. In practice, Baseline’s BI Scorecard is all about measuring the right things in the real world—not what it should be if the world was perfect. That is why we take into account the maturity level of the organization and develop an action plan for moving forward that matches the client’s abilities.

In the end, we met with everyone involved to present our findings. These meetings are not meant to be a blame game; they’re a learning experience. Each person, at some point during the meeting, was surprised by the findings, but all were told often that they were doing a great job under the current conditions. We worked out a series of next steps and milestones with them.  It was a win-win for business and IT, and a year later, they had reached a new level in their business intelligence reporting.

photo by Tony The Misfit via Flickr

---

Robert Stone has been with Baseline Consulting over 9 years and is a Managing Consultant responsible for leading and managing large and small projects.  He has over 25 years of IT experience with a diverse knowledge and skill base, and he's focused his skills on using technology to empower business users in many industries.

Where’s Your Stuff? The Importance of BI Program Artifacts

By Mary Anne Hopper, Senior Consultant

Do you have young kids with toys with little pieces all thrown together?  Do you have boxes of organized holiday decorations but every year the hangers or replacement bulbs are missing?  Do you have a Tupperware cabinet that is a constant juggle matching containers and lids?  Is your toolbox organized but the smallest screw driver lives in the kitchen junk drawer?

Now let me ask the same types of questions a different way:  Do you have a repository for your BI Program documentation?  Is it complete?  Can you find what you’re looking for?  Or, do important artifacts needed to support and grow the application exist in many different places?

Oftentimes, I see important BI documents buried in project folders.  This can be everything from database design to ETL design to source-to-target to data load scheduling.  Case in point, at a recent client, I asked to see a complete source-to-target artifact so I could add on to it for a second phase of a BI initiative.  I was given a link to a spreadsheet in a document repository and then two additional links.  The entire source-to-target picture of the environment was already stored in three places with the intent to create yet another one. The client’s reasoning? They didn’t have access to the right tools and all project artifacts had to exist in a certain place in their taxonomy for the project to be complete.

While many BI vendors offer knowledge management tools for BI projects, most of our clients are stuck with spreadsheets in the short-term. My recommendation to the client was to merge the various spreadsheets together and put them along with the accompanying program level documentation in a centralized location.  That way, one artifact could be utilized by future projects, resulting in reduced time and effort for next imitative.  And if they didn’t, important documents would continue to spread through their directory structure and future project teams would spend more and more time with each new project—as they tried to piece together what the application looks like and where their project needs fit, resulting in longer implementation timelines.

Next time you’re kicking off a BI initiative, take some time to think about what others need to know and what they need to find.  Be deliberate about creating—and annotating—your knowledge management system for BI. Some organization, process, and consolidation upfront will save you time the next time around.

photo by e0nn via Flickr

---

Mary Anne has 15 years of experience as a data management professional in all aspects of successful delivery of data solutions to support business needs.  She has worked in the capacity of both project manager and business analyst to lead business and technical project teams through data warehouse/data mart implementation, data integration, tool selection and implementation, and process automation projects.

Vendor SLAs: A BI Best Practice

By Alex Vilensky, Senior Consultant

Frequently on client engagements I noticed that even sophisticated BI and data warehouse development teams omit Service Level Agreements (SLAs).  Comments like “... Why should I bother amending my company’s service levels into the contract when the vendor should be handling that task...?” or, “Shouldn’t the vendor be telling US what the SLAs are?” underscore the point that development teams don’t consider SLAs a core responsibility.

Meanwhile your vendor is protecting its own interests. A down-the-road realization of a weak agreement with the vendor will likely occur once it’s too late for a “win-win.” The risk is cost overruns, low staff morale, and eroded vendor goodwill. Here is a list of some actual SLAs for BI vendors according to three different categories:  system performance, organization/people support, and application quality categories.

 System Performance

• BI application design screen refresh SLA’s (of 1 second, 6 seconds and 15 seconds) must be consistent with client’s refresh SLA’s of 2 to 7 seconds.  Vendor is expected to meet refresh SLA’s with additional hardware and/or application tuning.
• Data Warehouse daily batch runs are not must occur within the established 2-hour window. 

Organization/People Support

• Vendor ‘s support staff must have at least two client references per staff member.
• Vendor must be able to articulate changes from prior to current release in writing prior to installing the subsequent release.

Application Quality

• Code quality must be demonstrated (test cases) to be better than in the previous release prior to the release.
• Patch quality issues – ensure all patches are well tested without cause of problems elsewhere in the code.  For every iterative patch needed to solve a single issue, vendor must reimburse support credit dollars.

SLAs help to manage expectations and drive consensus.  They form a partnership bond with clear definition of the level of product and service support and escalation procedures when something goes awry.  In a mature production environment, clear service levels drive the long-term client/vendor relationship with concise expectations and clarity about the role and responsibility of each party.

---

Alex Vilensky has over 20 years experience in significant areas of information systems design and development including business requirements definition, logical and physical design, application development, technical leadership, project management, disaster recovery, systems programming, and database administration.