Blog: Dan E. Linstedt

« Redefining the "Data Warehouse" and Combining ODS+EDW | Main | IT: Changing from Cost Center to Profit Center »

Solving your Business Problems with RFI's

Have you ever wondered how to keep up with the barrage of technology these days? Have you begun an effort for enterprise integration, but are having trouble assembling the right team, understanding the technology, or getting an unbiased opinion from the right consulting firm?

I'm going to shed a little light on these different questions in hopes of helping you get your projects off the ground correctly.

I've spent part of my career as an employee, and another part as a professional services consultant. I've worked for PS at a software vendor, as a consultant for a systems integration firm who resold software, and now as a consultant for a systems integration firm who does not resell software.

There are plenty of differences. As a CTO I'm constantly tasked with

keeping up with technology.

I suggest that in order to answer the questions above, the enterprise first have a clear vision of where they want to be in 3, 6, 12, and 18 months. Setting milestones and goals is an important step to getting where you want to be. There are tools - no, not software tools - but consulting tools that can help you achieve your goals quickly.

Some of the keys to business success are as follows:
1. Either hire in-house talent (** you get what you pay for at this level), or bring in a firm to assist with the selection of qualified individuals for the project.
2. Read, read, read - this individual must begin to read the technology articles, blogs, web-resources, and learn to sift out the vendor hype from the reality of what can be done, and what should be justifiably done.
3. You've all heard this before: establish executive level support. Whether you're building an SOA, setting up EII, installing web-services layers, or integrating data into an Enterprise Warehouse - it is absolutely vital that the executives are behind the message, the people, and the process.
4. Establish Metrics, KPI's and KPA's in business help the project to progress in a timely manner. Without metrics the "project" is just a vision. In other words, accountability is paramount to success.
5. The business requirements should all be numbered, each requirement should then be tied directly to specific project plans; for instance, some requirements regarding metadata tie to POC projects, others tie to implementation projects, and still others tie to internal deliverables. This becomes the backbone/foundation for successful build out.

Of course these are just the top set of requirements. In order to answer the next question I put forward in the header of this blog let's examine some interesting facts:

1. Enterprise Integration (no matter what you call it), is a journey - not a destination.
2. Look to Systems Integration firms that do not resell software, for a truly unbiased opinion. If the SI tells you they "don't" resell software, but can do the work for a particular vendor, ask for references and the most recent project they've worked on which utilized that vendor of interest. Take the time to call both their customers and their consultants who were on the project and can describe the processes in detail, ensure their stories match.
3. Utilize templates, like RFP's, RFI's, and RFQ's - also utilize templates for vendor scoring. Sometimes what industry analysts provide in their studies is not enough - going through the process of vendor scoring can a. establish high level requirements and priorities, b. establish foundational metadata, c. speed the process of selection 3 fold, d. tightly define how the POC will be run and whom will be called in to meet the needs.
4. Architect, Architect, Architect – the three “locations” of successful projects, especially as they reach higher levels of visibility within the enterprise. I cannot stress enough how important a strong foundational architecture is to the success of these projects. I’m talking about architecture for business processes, architecture of systems (as-is, to-be), architecture of data and its integration, architecture of hardware. It is vital to know growth rates, user access patterns, and data integration patterns in order to put together the right architecture for the future. Without the right architecture, your project (for all intensive purposes) will need to be re-designed 3, 6, or 12 months down the road; and don’t expect it to be cheap! It will cost double what it costs to architect it properly up front.

A recent project I was involved in completed a POC in a couple of months and assisted in building a team, establishing executive sponsorship, documenting requirements, and vendor selection in Information Quality, ETL/ELT engines, VLDB RDBMS engines, Hardware platform selection, and Business Intelligence delivery. What made this a success was having proven best practices ready, vendor score-cards (and the metadata/business requirements for each), along with highly skilled focus on how the technology impacted the firm in different areas.

There are many more steps to this process which I will gladly discuss with you. What are you struggling with? What are you interested in? Let me know, and I'll post more about these interesting topics in hopes of helping you overcome these obstacles.

Share: