Cart
[Home] [By Thread] [By Date] [Recent Entries]
The next problem is getting someone to pay for the analysis, the tools, the design work, the implementataion and documentation, the training, and the redesigns for oopsies. But yes, without a thorough understanding, this is difficult to achieve. There are also granularity issues that directly affect process. Sometimes, big Ol'Hog Memo fields have a lot of different kinds of data in them. One group (the bean counters) want very deep granularity whereas the proposal writers and developers neither want nor need to track at that level yet are the data sources. And so it goes. I have seen attempts to use manufacturing paradigms (part = price) forced on software groups and fail miserably. len -----Original Message----- From: Michael Brennan [mailto:Michael_Brennan@A...] Sent: Thursday, March 07, 2002 5:46 PM To: Bullard, Claude L (Len); xml-dev@l... Subject: RE: RE: A Two Day Workshop for Software Architects > From: Michael Brennan [mailto:Michael_Brennan@a...] <snip/> > I specifically remember a VP going on a tirade threatening that > "heads would > roll" because he got two different reports from two different > IT groups that > directly contradicted each other on sales figures, and no one > could tell him > why. I can't resist an additional comment. This particular example is illustrative of my point about enterprises as federations. When this incident happened, some IT folks seized upon the opportunity to sell the notion of a data warehouse to the execs. It took awhile, but the execs eventually gave the go ahead. We had a very talented analyst (my manager, in fact) who spoke to the different groups and discovered there were in fact legitimate business reasons why the two different groups came up with different figures. They had different roles to fulfill in the organization, and those roles required different views of the data. But the individuals in each group had their minds so firmly entrenched in the perspectives of their own "fortresses" that neither could account for the differences. They simply had no understanding of the groups outside of their own fortresses. We could have adhered to the fortress model, and let the two groups duke it out endlessly trying to find out who was right and who was wrong. But the analyst instead simply clearly articulated an understanding of the roles each group played in the larger organization, and devised a data warehouse model that offered different views of the data associated with different organizational roles -- and very clear definitions of those roles and their areas of applicability. So both groups were right, but it took a holistic view of the larger organization to see that and articulate that. This data warehousing effort was quite successful, and the execs no longer fretted about the fact that different groups produced different figures because they understood *why* and they understood what view they needed to select from the warehouse to get the figures they needed for decision making. That's why I said in my original post that technical solutions will get you nowhere if you don't understand your enterprise. There is no proxying technology or integration solution that would have solved the above problem. It took business analysis, with a perspective toward modeling the enterprise, not individual fortresses.
|
