1. ENKI LLC
Executive Consulting
Creating Optimized
Business Relationships
First in a series
An Enterprise Framework Series
An Enterprise Framework Series by
Lawrence Dillon
© 2002 - All Rights Reserved

2. Creating Optimized Business Relationships
© 2002 - All Rights Reserved Lawrence Dillon Page 2 - 6
ldillon@enkillc.com
Introduction
Reducing time to deploy new technology solutions has been promised to corporate America for
more that 25 years, albeit with little success. The emergence of Adaptive Systems Development
(ASD) in 1979, Rapid Application Development (RAD) in 1990/91, Rational Unified Process
(RUP) in 1996, eXtreme Programming (XP) in the late 1990’s, and Agile in 2001 were hyped as
silver bullet solutions. However, several studies continue to show that businesses remain
disappointed by the technology solutions they receive with project failure rates averaging 71%.
This continued inability to meet customer expectations demonstrates that there is a bigger need than
just technology methodology, reusable code, harvesting, data mining, big data, Software As A
Service (SaaS), Infrastructure As A Service (IaaS / Cloud) or other current buzz word to improve
technology department performance.
Doing the right thing
Information Technology (IT) departments have a strong history of trying to do “what is right” by
doing what the business units request. However, there are business unit executives that believe IT
departments do their own thing and don’t listen. You know that IT is one of the few groups that
have insight into the operations of the entire enterprise. This enterprise insight can drive technology
in a direction that individual business units do not appreciate since the technology direction may
conflict with the business units’ own view of technology. To help resolve this potential conflict,
some system groups have learned to help business units by defining what needs to be accomplished
through leading the “business requirement” gathering effort and providing enterprise standards. Yet
there is stall a practice that should be stopped - IT groups identifying technology projects that
business units appear to need and then creating them with little input from the businesses units.
Finding accurate success metrics is very difficult since the IT development efforts can succeed
because the IT goal is met yet they also fall short or completely miss addressing the business need.
There are a number of research studies, including a few from the University of Indiana and
Software Productivity Research, Inc., which show the majority of system development efforts do
not meet business needs. Some studies claim a 75% failure rate based on business use of
technology while others are more conservative and claim a majority of technology efforts fail to
meet business requirements. If we measure IT productivity as the ability to deliver technology
enablers to improve business performance, and believe the studies, than “doing the right thing”
does not seem to be working. So, what can we do to improve what technology departments deliver?
Identifying areas of improvement
First there is a continuing need to focus on the hard part of business management, finding where
there is potential for improvement. Potential improvement can be observed in different ways and
everyone must be open to the myriad of opportunities. Keep in mind these are not addressing
symptoms but rather root causes or potential opportunities. So, asking cross business questions can
often help uncover unexpected opportunities
• Where are business units similar – processes, employee skills, or technology?
• Can technology components of a single system be reused for multiple business units?
• Can re-architecting systems to be component based or service based help reduce redundant
development efforts?

3. Creating Optimized Business Relationships
© 2002 - All Rights Reserved Lawrence Dillon Page 3 - 6
ldillon@enkillc.com
• Will an Investment Portfolio Management (IPM) process identify redundancy or highlight
opportunities earlier in a project’s lifecycle?
• Is there a full-time businessperson on every technology team? If not, is the work
important to the business?
The concept of business reengineering is driven by the opportunity to identify unnecessary
complexity and redundancies within business areas. The reason this is important to you is that there
are lessons learned from reengineering that apply to the improvement of technology departments.
With a structured Enterprise Framework, every company can quickly discover their systems running
today that enable similar processes across different business units (technical or business systems).
The larger the company is, the more likely the redundancy.
The driving reason for this apparent waste varies, but generally there are three underlying business
reasons:
1. Business Units make the money so they direct their own IT needs – isolated development
2. Technology Departments attempt to meet the Business Units’ needs the best they can and
often create isolated groups for each department whose budgets are driven by the amount of
money the business unit spends on IT – isolated business unit support
3. Company Reward and Recognition systems encourage particular, short-term, behavior. For
example, business executives are often rewarded based on quarterly results and technology
executives are rewarded by completing projects on-time and within budget. Neither are
rewarded based on value of the technology enabler(s) across the entire corporation if that
work requires missing a single business unit’s target – business unit profit driven
Addressing the inhibiters
Business Driven IT Development
Business units have the money to pay for IT development efforts. I am not questioning where the
money is or who should pay for technical enablers; I am rather highlighting a more latent point of
funding technology initiatives. Enterprise technology development is a tricky balance of business
need, money, time, quality, strategy, experience, and business intuition.
If technology is driven by several concerns, why let money be the only consideration? Every Chief,
(CIO, CTO, COO, CFO, CEO, CMO, CSO, CAO) that I have encountered has told me they know
that business unit drive development inevitably create redundant systems (as depicted in Figure 1 -
BU Driven Technology) and they could save millions if not hundreds of millions by identifying and
eliminating these redundancies. As it turns out, most of these executives have one of two situations
they are dealing with. First; they do not have the organizational leverage to remove redundancies.
For example: a corporate CIO may not be able to tell a business unit CIO to use another business
unit’s solution to address shared processes. This could be driven by political clout or the ability to
fund the shared solution. Second, the executive may intuitively understand they have redundant
solutions but does not have the time or understanding of how to identify the redundancies and hence
cannot move forward. For instance: An organization that is attempting to harvest1
reusable
technology is going down a high risk path. To build duplicate solutions and then hope to find the
1
Harvesting is the effort of finding duplication in technology after it is in production. Discoveries could include
duplicate databases, applications, messaging solutions, platforms, and even hosting providers.

4. Creating Optimized Business Relationships
© 2002 - All Rights Reserved Lawrence Dillon Page 4 - 6
ldillon@enkillc.com
Business Units
BU Processes
BU
Applications
Technology
Driven Reuse
& Harvesting
Figure 1 - BU Driven Technology
duplications later requires bringing in your best and brightest technologists to identify the
redundancies. Removing the best and brightest from the fieldwork inevitably increase the numbers
of redundant solutions because less experienced people are left behind to address the business unit
needs. These people, although bright and hard working, may not have the cross unit experience to
know that a problem has been solved elsewhere, inevitably creating a snowballing of continued
harvesting efforts with little or no business unit impact (as seen on the bottom of Figure 1 - BU
Driven Technology).
Regretfully, harvesting reusable technology by its nature is a costly endeavor because it requires
some of the most experienced people to perform well. So, a harvesting effort is a high risk
approach since the initial cost is high and the possibility of business units continuing to create
redundant solutions is also high. Additionally, the problem is perpetuated by increasing the focus
on quarter to quarter results while ignoring the strategic implication of shared technology. To
highlight the risk of continuing down this path, imagine if accounting was driven this way and every
business unit had their own chart of accounts, accounting standards, principles, processes and
reports. Picture the amount of confusion around what a company really earned, if costs were under
control, if vendors were giving the best price, or even the real number of customers. I cannot
comment on what a company would look like if all of the accounting standards were ignored, but I
picture Enron and WorldCom as examples of what ignoring some controls in a particular area could
impact. If effective information management, and hence knowledge, is the future of differentiation,
we must consider an approach that has demonstrated results but less risk than harvesting.
Business Unit Partnering with Technology
Business executives are doing the best they can to address known business issues, redundancies and
problems given the authority and leverage they have within the company. The truth is that not all
executives are created, listened to, or rewarded equally. Great executives could have a relatively
small business unit, or worse yet a cost center, and hence little influence on the overall direction of
a company driven by business unit revenue or bottom line contribution. Some of the most creative

5. Creating Optimized Business Relationships
© 2002 - All Rights Reserved Lawrence Dillon Page 5 - 6
ldillon@enkillc.com
solutions I hear about originate from executives of the smaller business units. These same
executives also seem willing to assume an unfair share of cost for the benefit of the entire company.
For example: if a smaller business unit is going to share the cost, equally, with a larger business
unit, there is a possibility that the shared cost would be greater than building a redundant solution
since the smaller unit may not require as robust a solution as the larger unit. This could be due to
the number of transactions, call center needs, distribution architecture requirements (global or
local), and even the required technical tools (Microsoft solutions verses IBM solutions) my increase
the overall cost. A smaller business unit may be able to use a small package with minimum support
needs and an overall cost of a few hundred thousand dollars. A larger business unit may require
99.999% availability with 24X7 support to handle 700 times the volume with a global client base in
several different languages including double byte support. The larger groups’ solution may cost
many millions of dollars and the smaller unit would have to share 50% of the cost.
So, using traditional metrics to justify current performance may not help leading edge executives
with little bottom line influence change the direction of an entire enterprise. A best practice
approach leverages metrics that catch the eyes of the larger business units such as metrics that show
the waste or opportunity. Showing how many existing systems support similar business processes
is a way to get high-level attention. For instance, I worked at a company that had 56 systems
supporting the same business process. Each system cost tens of millions to create and a couple
million a year to support. After analyzing the systems and business units, it was obvious that there
were 50 to 53 too many systems.
Many business units would claim that they are too different to use the same system as another
business unit, as was the case in the aforementioned example. This claim is usually not true but
every business unit employee will give you reasons why they are different. I have worked in over a
dozen industries with dozens of global companies and there is absolutely one thing I have learned,
Business Units
Shared Processes
Enabling
Shared
Application
components
Unique BU
Processes
- and rules
Unique BU
components
Figure 2 - Partnered driven technology

6. Creating Optimized Business Relationships
© 2002 - All Rights Reserved Lawrence Dillon Page 6 - 6
ldillon@enkillc.com
there are more similarities than there are differences. The lesson learned is that business executives
should focus on these similarities if they wish to have a cost effective operational environment.
These executives should insist that business units with shared needs leverage the ability of current
technology to provide a single solution and create exception processing for the unique business unit
processes that are identified as necessary, as depicted in the bottom of Figure 2 - Partnered driven
technology.
By viewing business processes as distinct entities, you can align technology components to each
exclusive process. In effect, this view allows you to align a business architecture to a technical
architecture, similar to aligning plumbing and wiring to the layout of walls in a house or building.
If a process is shared by two or more business units, it makes sense for the process to leverage a
single technology enabler instead of each business unit creating their own solution. The issue that
some companies have to deal with is that business units often have their own technology group.
Without a coordinated effort between business units, there is a high possibility of solving the same
problem twice. However, centralizing technology is not the answer either since this can slow the
development of business unit specific needs. So, a strong business partnering must occur with the
understanding that the partnership is for the sake of enhancing technology support and maintenance
while ensuring they are cost effective for the entire enterprise. If an Enterprise Business
Architecture perspective is used, as depicted in Figure 2 - Partnered driven technology, shared
business processes and activities can be identified and technology support can be aligned and
optimized appropriately.
Today’s technology allows for such standardization and specific modification through the use of
component based architectures. Shared processes can and should share specific technology
components. These shared components should be maintained by a group that is more centralized,
i.e., driven by a business partnership verse drive by a single business unit. If a business unit wishes
to enhance or reduce functionality, the functionality is created and maintained by the business unit
technology group. As long as all required functionality and information is still shared, the
reduction or enhancement of functionality is for business differentiation and not a fundamental
change to the underlying business or technology architecture. However, this should be worked
through with the business partner(s) to ensure that there is not a change to the underlying
architecture.
Conclusion
If business unit and functional leaders are encouraged to partner together, where legal, and to work
with business partners in an enterprise level technology group, there are opportunities to improve
operations and reduce costs. By identifying what business units share and focusing on developing
technology enablers to support these shared areas, corporations can balance the efficiencies of
business unit focused technology teams with the operational benefit of a centralized technology
group. By allowing business units to enhances or extend system features to address business unit
exceptions or unique processes, corporations can benefit from the flexibility created by smaller
groups to address their target markets. The technology exists to create systems that support this
approach; it is now time for executives to implement this approach.