It seems I’m frequently in conversations about using null to represent a business value. To paraphrase, say there are credit and cash customers, and there’s a suggestion to set “Customer_Type” to “C” for credit and null for cash. To data and database professionals this is obviously a bad idea, but it’s not obvious from a business point of view. Continue reading »
Apr 052009
While many organizations understand the value of managing the information resource, for many others information management remains abstract and difficult to define. In an effort to make it concrete here’s a hypothetical proposal to provide an Enterprise Information Architect for a hypothetical organization that really needs one. Continue reading »
Mar 252009
Excerpt from "Show Me the Money: A DM/BI Business Value Primer", Bob Lambert and Tri Truong, Information Management Special Reports, March 24, 2009
Before starting the Business Intelligence business case, the BI advocate should do the homework required to ensure its success, including these essential steps:
1. Know the organization’s goals and objectives.
2. Identify a BI champion.
3. Identify and work with BI stakeholders.
4. Identify an application with tangible business value.
5. Define and quantify a quick win prototype project. Continue reading »
Mar 182009
Excerpt from "Protecting Your Data with Row Level Security for SQL Server Databases," March 17, 2009
Data security is not optional in today’s business environment. High-visibility hacking and fraud, Sarbanes-Oxley, HIPAA regulations, and the Patriot Act all reinforce the need to present the right data to the right users and prevent the wrong ones from gaining access. Typically, “row level security” (RLS) is one requirement: to allow or permit access to particular users based on data in a particular database row. SQL Server does not provide built-in row level security. Continue reading »
Here’s a little-recognized fact about data integration: if you run a business or any sizable chunk of one, someone is integrating your data.
In my professional life I have on occasion suggested data integration efforts. Sometimes my suggestions have been accepted and sometimes not. As an IT professional I understand that different managers have different priorities, and in a given business situation sometimes other things are more important for example than having a single, consistent source for all customer records, or making sure production data matches financial data.
But as a customer? That’s different. Continue reading »
History is littered with IT application projects that end late, go way over budget, or abandoned altogether. I was fortunate enough to see one work out really well (almost – please read on). It was no mistake. It came down to a simple method advocated by a gentleman named named John Carpenter.
The project was an HR management software conversion from one commercial off-the-shelf software (COTS) package to another. The company concerned was conservative about spending money. A previous business case had proposed a similar project. The problem with that business case was that the benefits were really tough to conceptualize, so the cost/benefit analysis relied on soft benefits like “improved access to information” and “more consistent reporting data”. The folklore was that the CFO had physically thrown that business case out of his office. Continue reading »
Excerpt from "Illusions, Allusions – Let’s Get Real about Database Design", October 4, 2002
Much of today’s IT application development – custom or off-the-shelf – involves integrating data from legacy systems, third- party software products and external data sources such as demographics or mail lists. More often than not, data integration is unexpectedly complex, either due to data quality issues or the nature of the data integration itself. Continue reading »
Feb 132009
Recently I was asked for a high level requirements plan for a large IT conversion. I googled around a little for something standard. I found some good references (see links at the bottom of this post), but not exactly what I was looking for: a simple, method-agnostic layout of the high level steps and checkpoints in requirements for a big project, emphasizing interactions with business people. I then rifled my files to find the example below. Continue reading »
To me, calling someone a “user” contributes to the gulf between IT and other business people. Continue reading »
Free form diagramming doesn’t only mean “no rules”, it also means “just right”.
This post, last in a three part series on free form diagramming, gives some simple guidelines for getting the technique right. Part one talked about the tension between rigor and expression in diagramming for analysis and design, and how more precise diagrams can hinder rather than help communications with business people. Part two reviewed free form diagramming in practice.
While it is impossible to specify format and structure of a free form diagram in advance, here are some useful guidelines to follow when building your free form diagram:
• Rule number one: draw it as you see it. Typically, an analyst uses a free form diagram because he/she already pictures a business process. Trust your mental picture and get it down on the page. Then, go through the following checklist to make sure it says what you want it to say.
• Model real world processes, things, and events. Free form diagrams have one great advantage over Use Case Diagrams, Data Flow Diagrams, and the rest: they are concrete rather than abstract. For example, in a free form diagram you can symbolize a shopper with a clipart picture of someone choosing a soup can from a grocery store shelf. The free form diagram should clearly represent things from the real world: organizations, locations, business processes, interfaces, etc.
• Use symbols consistently. Look at each repeated rectangle, line, circle, icon, etc, and verify that everything with the same shape represents the same type of thing or event.
• Speak the language of the audience. A free form diagram should depict things business people care about in recognizable terms. For example, accountants might readily understand boxes labeled GL, AP and AR for general ledger, accounts payable, and accounts receivable. A shipping clerk might quickly interpret a process illustration showing labeled icons shaped like trucks and warehouses.
• Arrangement on the page conveys meaning. Frequently, free form diagrams group objects that belong together on the page. In other cases, the diagram shows a definite process flow by the arrangement of objects. For example, Business Intelligence Architecture diagrams typically show information flow from source systems on the left to business reporting on the right. Could this kind of flow or grouping improve your diagram?
• Limit the number and complexity of objects on the diagram. Most often, a meaningful diagram shows relatively few objects, organizes them in a sensible way, and does not cross lines. If you need many objects to tell the story, reduce complexity by arranging them logically.
• Work at one level of detail, or clearly indicate differences between levels of detail. If your diagram includes a box labeled “AP System” then it would not likely make sense for it also to contain another labeled “Journal Voucher Key”. Diagrams that communicate well are all at the same level of detail or clearly indicate differences in level of detail.
The free form diagram can be an essential part of a successful IT application project by enabling all to understand the target system in the same way and helping business people understand critical functionality.