[
Lists Home |
Date Index |
Thread Index
]
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@Allegis.com]
Sent: Thursday, March 07, 2002 5:46 PM
To: Bullard, Claude L (Len); xml-dev@lists.xml.org
Subject: RE: [xml-dev] RE: A Two Day Workshop for Software Architects
> From: Michael Brennan [mailto:Michael_Brennan@allegis.com]
<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.
|
