The Object Management Group
"Strategic Approach to
Value Chain Integration"
Business-to-Business & Business-to-Customer
Relationships, transactions, and interactions between customers and
business have changed dramatically over the last 3-5 years and continue
to define a new electronic business model known as e-business. With the
change in consumer buying habits and the growing need for information,
the customer has begun to expect businesses to empower them. As a
result, businesses can benefit by allowing customers to own more of the
buying process. However, in order for customers to help themselves
through the buying process, businesses must provide the enabling
technology for the customer to use. In addition to business-to-customer
e-commerce, business-to-business transactions are estimated to be 7 - 10
times the number of business-to-customer transactions. The key question
is not who will be involved in business-to-business e-commerce as
e-commerce itself is not a new concept. The key question is how will
businesses integrate their heterogeneous applications with so many other
businesses in an efficient manner?
Regardless of whether you are considering business-to-customer or
business-to-business e-business, both require a value chain1
focus. Integration of your value chain allows you to extend your
services further down the value chain to better manage the process or
further up the value chain to own the customers total experience. What
does this mean to business? Integrating processes and applications which
are part of the value chain, can lead to increases in revenue, higher
customer satisfaction, new opportunities to offer packaged
products/services, fewer defects, better visibility / control, and many
more benefits.
One of the goals of technology should be to remain open and flexible
to support the changing objectives of the business. So, how do we remain
open and flexible with so many past, present, and future technologies?
Since we also can't dictate the architectures of our customers or
suppliers (except in rare cases), we must work with their existing
technologies and business processes. If we could find such a solution,
we would be able to mitigate the risk of developing stand-alone obsolete
solutions by providing upfront the ability to leverage our technologies
over time.
With a vast majority of the core Platform application functionality
completed already in the form of vendor developed components, what then
should a business moving into the integration of the value chain focus
on for business-to-customer and business-to-business e-business? The
answer is common domain interfaces. Common, industry-wide domain
interfaces are the key to a flexible architecture and the OMG has the
process, experience, and proven architecture to make your e-business
strategy a reality.
In addition, the specifications that OMG provides and continues to
create cover the entire application integration and development process,
so you can be sure open specifications are available to you from the
time you gather your requirements until the time you deploy or integrate
your applications. Proven specifications like the Unified Modeling
Language (UML®), Meta Object Facility (MOF), CORBA®, CORBAservices,
and Domain work together ensure the entire requirement, development and
construction processes are covered instead of a single phase.
The Object Management Group (OMG) will continue to develop industry
recognized core foundation technology (Platform) and will continue to
offer interoperability to new and emerging technologies to ensure your
investment today will still be valuable tomorrow. We will continue to
help design standard interfaces for Domain specific functions internal
to your line of business and we will also begin to form specialized
subgroups with a mission to define the "Domain Public
Interfaces" found between your disparate lines of business, your
customers, suppliers and competitors.
Overall, our focus is to help members define open architectures and
interfaces that will remain as the enabler of application integration
for the business-to-business and business-to-customer e-business models,
and the entire value chain of your business.
Relationships, transactions, and interactions between customers and
business have changed dramatically over the last 3-5 years and continue
to define a new electronic business model known as e-business. The
emergence of the Internet has offered a new way of conducting business
that before would have been prohibitively costly and unacceptable to the
consumer only a few years ago. With the change in consumer buying habits
and the growing need for information, the customer has begun to expect
businesses to empower them. Customers today want to help themselves. As
a result, businesses can benefit by allowing customers to own more of
the buying process, thus eliminating that portion of effort from their
overall expenses. However, in order for customers to help themselves
through the buying process, businesses must provide the enabling
technology for the customer to use and have a thorough knowledge of
their customer. Customers who were once presented with
"generic" offerings can now effectively be offered "Mass
Customization" options. The use of data mining or knowledge
discovery will also be very important as businesses learn more about
their customers to better satisfy customer requirements.
With customers choosing to become more involved in the procurement
process, businesses today are faced with difficult challenges. How do
they own the customers total experience amidst a rise in competitive
pressures and advances in technology that make it easier for customers
to choose alternative business offerings? Products once thought of as
specialty goods are now becoming commodity products as the distance
between the customer and the manufacturer collapses. With
differentiators such as customer satisfaction equating into direct
market share, the race to integrate further up and down the value chain
becomes even more critical. The ability to control the customers total
experience will likely result in higher levels of customer satisfaction;
which can equate into customer retention, new customers, and bottom line
results.
To properly manage the value chain and ensure the trust of the
customer, businesses will also need to guarantee both a robust
architecture and proven Quality of Services throughout the entire value
chain. Quality of Services, such as proper security, transaction
control, messaging, and many more services are required throughout the
life of the transaction, not just from the GUI to the application
server, but throughout the entire value chain.
Although emphasis today is to capture market share by establishing
business-to-customer relations, business-to-business transactions offer
greater opportunity in terms of dollars and transactions. By comparison,
business-to-business transactions are estimated between 7 - 10 times the
number of business-to-customer transactions. Estimates place the annual
business-to-business opportunity near US$900 Billion vs. the value of
business-to-customer transactions at approximately US$80 Billion.
The stakes are high. The opportunities abound. The key question is
not who will be involved in business-to-business e-commerce, but how
they will integrate their heterogeneous applications with so many other
businesses in a manner that is advantageous to all parties. The
requirements for business-to-business transactions include those of the
business-to-customer, but may need to account for higher transaction
volumes, better audit trails, and tighter security as a result of
internal or external pressures (e.g. regulation). Most importantly,
business-to-business transactions will require the ability to integrate
applications (or systems) that were designed, developed, and implemented
by two or more different parties. The business-to-business model becomes
more complex when you consider the effects of integrating value chains
between many suppliers and many customers. And remember, a supplier for
one business is a customer to another. The problem becomes very clear in
this context and the need to integrate portions or whole applications
becomes a critical success factor in succeeding with a
business-to-business e-business strategy.
Regardless of whether you are considering business-to-customer or
business-to-business e-business, both require a value chain focus2.
Both business-to-customer and business-to-business e-commerce strategies
require integrating processes and application systems with several
suppliers and many customers. A few of the benefits are included below.
Integration of your value chain allows you to extend your services
further down the value chain to better manage the process or further up
the value chain to own the customers total experience. What does this
mean to business? Integrating processes and applications which are part
of the value chain, can lead to increases in revenue, higher customer
satisfaction, new opportunities to offer packaged products/services,
fewer defects, and many more benefits. It allows your business to remove
non-value added steps in the process and reduce waste and/or cycle time
in the process which equates into bottom line dollar savings for your
business.
From a business standpoint, integrating systems, eliminating waste,
reducing defects, and the many more benefits identified above all lead
to real business value for stockholders. The challenge is how to
integrate such an assortment of different processes and systems
technically, while ensuring a flexible solution that will work with the
technology you invested in the past, technology you are using today, and
future technology yet to be discovered.
If we knew the architectures, design standards, coding standards, and
implementation processes of just one of our suppliers, we might be able
to build an interface for this one supplier. But what about the other
suppliers we have? What happens if we change suppliers? We can't afford
to use our limited budget to develop solutions, which work today for a
particular vendor, but then need to be re-budgeted and staffed year
after year for changes. Our goal is to remain open and flexible. So, how
do we remain open and flexible with so many past, present, and future
technologies? The answer is explained in the remainder of this strategy
paper.
Since we also can't dictate the architectures of our customers or
suppliers (except in rare cases), we must work with their existing
applications and processes. We know we need a secure way of integrating
our value chains, but we must be sure we have a proven security service
that handles transactions securely between our business and our supplier
or customer. We also said we would need to record transactions and
maintain an audit record, so it will be important to have a service
which provides this functionality. Lastly, we need the ability to
permanently (or persistently) store information for trend and/ or
historical purposes. Regardless of the e-business model chosen, these
services (and many more) will be required before we begin to think about
integrating applications. To ignore this basic foundation and integrate
value chains without these services would be accepting undue risk for
your stakeholders.
We said we needed an open solution, not just today, but for future
technologies yet to be introduced. We can't consider using an immature
solution unless we are again willing to increase the amount of risk to
the business; should this immature technology evolve into our next
legacy application. However, let's consider the optimal solution. One
which provides a flexible solution that allowed us to integrate future
technologies with our current and past technology investments. If we
could find such a solution, we would be able to mitigate the risk of
developing stand-alone obsolete solutions by providing upfront the
ability to leverage our technologies over time.
As we mentioned earlier, core fundamental services will need to be in
place before integrating multiple applications. But what about the time
required to build these services? Time is money. Unless these services
are technically insufficient, technically immature, or the cost of
ownership is prohibitive, businesses can't afford to develop these
services on their own. The speed of business is moving too fast and a
flexible solution is required today, not months or years from now.
Fortunately, the benefits associated with object technology and
component development allow us to buy pre-built solutions, integrate
them into our application, and deploy systems in very short cycle times.
By using work that is already complete and offered by vendors (e.g.
security, transaction, notification, etc.), businesses today can begin
integrating the value chain immediately. The foundation services, if
purchased rather than built, would result in substantial savings in
man-hours and/or time. If enough of these components were available and
interoperable, then a lot of work required to integrate applications
would be already complete. Additionally, if these components were
inserted into a flexible architecture, which allowed for integration and
interoperability with past, present, and even future technologies, then
technologically speaking a business would be ready to begin integrating
NOW.
However, integrating value chains involves more than just technology.
First and foremost, are basic economic concerns that must be satisfied,
followed by evaluating the process maturity of the entire value chain
for both businesses. Only after this, can you gauge the likelihood of
success. Are our processes mature enough to allow for the integration
with our suppliers and customers? Have we assessed our own internal
readiness and determined that we can offer the additional services that
might be part of our newly extended value chain? Are we prepared to
consider outsourcing a portion of our value chain that would be better
managed by another supplier with core competencies in that particular
area? Given that we need to consider international implications in our
strategy, (e.g. European Data Privacy Initiative as one example), an
e-business solution must consider global sourcing.
Each business will be at a different level of process maturity and
will need to determine their readiness and effectiveness before
beginning to integrate their value chain to conduct e-business.
An architecture exists today which provides for the flexibility we
considered as "optimal". This architecture is the Common
Object Request Broker Architecture (CORBA®) and has been developed by
the largest software consortium, the Object Management Group (OMG). The
Object Management Group started more than 10 years ago "...to
create a component-based software marketplace by hastening the
introduction of standardized object software. The organization's charter
includes the establishment of industry guidelines and detailed object
management specifications to provide a common framework for application
development.". CORBA® has grown to be the de-facto standard for
flexible interoperability and heterogeneous application integration.
Today, there are many implementations, success stories, and examples of
proven value added benefit achieved using the open and flexible
architecture of CORBA®. As a proven architecture, multiple CORBA®
vendors are available to choose your implementation. CORBA® has defined
interoperability with Java, C++, C, Ada, Smalltalk, XML, EJB, COM/DCOM,
and will continue to provide interoperability between disparate
technologies not just now, but throughout your e-business strategy; even
into the future.
Since not all businesses or departments within businesses will be at
the same process or technical maturity, there is a need to participate
at different levels of interest based on where you are in your specific
business. The OMG considered this and is focused in two separate, but
complimentary areas. For those who are interested in contributing to the
success of the technical interoperability, there is the Platform group.
This technology group is focused on Analysis and Design methodology
(e.g. Unified Modeling Language or UML®) and interoperability issues
such as making sure new technologies interoperate with other
technologies (e.g. EJB and CORBA® Component Model (CCM), C++ and Java,
etc.).
For those interested in integrating their value chain or internal or
external applications, there are several Domain groups working to define
common interfaces by which integration can be achieved. So whether your
company is just starting with the integration of your value chain, or if
you are ready to help define the industry interfaces, the OMG has the
methodology, proven success record, and forum to help you achieve your
desired level of participation.
We also discussed the need to have robust services. CORBA® provides
a complete set of services that are stable in businesses around the
world. There are several services to choose from (all based on the same
specification), and together these services make up the foundation upon
which future technologies will interoperate. The building blocks are
there...so, there is no need to spend un-necessary resources or time
re-inventing the wheel. By one estimate, as much as 30-70% of an
applications functionality is already enabled by the CORBAservices. This
allows you to focus on the domain or business logic necessary to
integrate your applications and we will support you in this activity
with the Unified Modeling Language (UML®) and Meta Object Facility
(MOF). This leaves the "basic building block" work to your
vendor.
With most of the core application functionality completed already by
vendor developed components, what then should a business moving into the
integration of the value chain focus on for business-to-customer and
business-to-business e-business? The answer is common domain interfaces.
Common, industry-wide domain interfaces are the key to a flexible
architecture. Just look at your own value chain. How many of your own
internal interfaces are based on industry standards? How many interfaces
are generic and agreed to by all of your suppliers? I would venture to
say that in many domains, custom interfaces built to support a single
supplier or customer are rampant and although similarities are common
across all of your suppliers and customers, I doubt consensus was
reached prior to implementing the interfaces. After all, you probably
added them slowly over time as your business needs changed, rather than
all at once. Business needs in the past didn't necessitate that entire
value chains come together and define common interfaces. However, the
value that can be gained today in defining and using common interfaces
for your customers and suppliers, as well as interfaces that you will
use as a customer of other businesses, will make integrating value
chains a reality not just now, but into the future.
As depicted by Model 1, a generic value chain has been constructed
and divided by suppliers, the company, and customers / stakeholders. The
company uses the CORBA® architecture in conjunction with the open
services we discussed to form their foundation. The company then works
on one or more Domain focused Task Forces that are of interest to the
company. This is often based largely on the need to standardize
throughout an organization, either horizontally between functional areas
(e.g. Finance and Manufacturing), or vertically from one end of the
value chain to the other end. As the model depicts, the second column
shows Banking/Financial Services as the supplier to the company.
Internally, the company will have a Finance department, and may have
Financial Analysts or Stockholders as its Stakeholder(s). Today, the
internal functions (e.g. Manufacturing, Finance, etc.) are being worked
intently and an example of the work in the Manufacturing Task Force is
included. Another benefit for standard specifications is the Domain
Interfaces between the Company and the Suppliers & Stakeholders.
This is the area for tremendous growth in the e-business model and a
critical place to develop Domain Interfaces to help integrate value
chains. Without these common interfaces defined, an exponential number
of interfaces may result and make integrating value chains between
suppliers, the company, and stakeholders economically or technically
unfeasible.
Another growing trend is the number of outsourcing opportunities
throughout the industry. The ability to define and use common interfaces
is a key enabler to outsourcing. If your interfaces are consistently
applied, proprietary processes are not a requirement to administer the
interface(s). This allows you to detach the value added work (which
forms your competitive advantage) from your technical requirements and
the work can be easily outsourced. The benefit of outsourcing may be
lower operational costs, higher productivity by assigning your employees
to higher-value work in the value chain, and higher quality if the
technical portion is outsourced to a business with core competencies in
that particular area.
The first question to answer is what is my process and organizational
maturity and should I focus on the common Domain interfaces inside my
business or outside my business, or both? Both internal (intra) and
external (inter) strategies are beneficial and will likely result in
cycle time reductions, cost savings (both hard and soft), and
flexibility infused into the business process and value chain (see Model
2). You know where improvements to the value chain could lead to the
most return for your stockholders, so most businesses begin there.
However, the primary determining factor when considering if your company
should focus on defining and using internal or external interfaces is
based on several criteria; namely, the process maturity of the business,
amount of work required, cooperation in the industry and with your value
chain partners, probability of success, Return on Investment (ROI),
Return on Assets (ROA), and others.
One of the first things to consider is the silo strength (or culture)
in the organization. Ask yourself and your other functional leaders
whether it would be easier to integrate with your own suppliers &
customers, or with each other. Since internal culture is very difficult
to change, you may in fact see faster benefits by focusing outside your
business initially and working with the OMG to define common interfaces
between your suppliers and customers. Additionally, you will want to be
realistic about organizational dynamics as this will help you determine
your risk accurately and will likely be a good indicator of the
probability of success should you pursue an internal focus.
As with most businesses, some departments will be more open and their
processes will be more mature. These portions of the business are ready
to define industry standards external to their own business. As we
discussed earlier, the OMG offers different levels of participation
based on your particular growth and development in technical maturity.
Given the varying levels of maturity, a business will likely have both
an internal & external strategy and actively solicit input from the
entire value chain to work throughout the entire chain rather than just
focus internally or externally.
We've spent a lot of time discussing e-business and application
integration from a value chain perspective. Our next discussion point
should be on the breadth of the OMG's specifications throughout the
entire application integration and development process. How well is the
OMG prepared to help from the time I gather my customer requirements
until the time I deploy or integrate my applications? The answer is from
start to finish. Model 3 depicts a typical system development life cycle
including the requirements, analysis, design, construction, testing,
deployment, and monitoring / maintenance phases. As you can see in the
model, the Requirements, Analysis, and Design phases are addressed by
the Unified Modeling Language (UML®) and the Meta Object Facility (MOF)
specification, which is an OMG adopted specification and owned and
maintained by the OMG member community. Tools are readily available
today that are based on the UML® and MOF specifications and provide
business value for these critical early phases of the process.
We discussed earlier the work of the Platform and Domain groups and
their specifications have formed the foundation for CORBA® compliant
and branded Object Request Broker's, CORBAservices which act as the
basic building blocks required by most if not all applications, and
Domain specifications used to define common interfaces for business. The
specifications developed by these groups have become implementations
offered by various vendors and are readily available today. The CORBA®
specifications defined the ORB and various other facilities required by
the transport layer. Much of the complexity required to manage
communication between layers is handled by the ORB and simplified for
the developer. With the commercial availability of CORBAservices built
from the OMG specifications, another portion of work can be purchased,
rather than constructed. However, the option always exists for a company
to develop their own CORBAservices, based on the OMG specifications.
The introduction of CORBA® components once again reinforces the
OMG's commitment to open standards and a flexible architecture for the
changing needs of business today. CORBA® components tightly integrate
with the CORBA® specifications and the CORBAservices specifications to
simplify even further the effort required by the development staff to
build or integrate robust applications. CORBA® components work with
EJB's and many other languages, so whether you are working with C,
COBOL, Java, EJB, or some other technology, CORBA® components will
enable your architecture to remain open and flexible.
As the Domain specifications continue to grow, the next level of
commercially available services for application integration and
development will be available and companies can choose to purchase an
implementation or code to the OMG specification. Keep in mind that
coding to the OMG specification will ensure flexibility in your
architecture; just one of the critical success factors that we discussed
earlier.
All of these specifications can be used in the design phase during
the integration or development. Imagine designing flexibility into your
project very early in the process...even without knowing what
implementation language you will choose. As the construction phase
approaches, make vs. buy options present themselves and based on your
businesses core competencies, you can then decide if developing the
specification or purchasing the specification is better aligned with
your business needs. As deployment nears, interoperability found in the
OMG specifications offer you flexibility and an open solution that will
work with legacy systems, your present development, and future
development that hasn't yet been invented.
The Object Management Group (OMG) will continue to work on the core
foundation Platform technology and will continue to offer
interoperability to new and emerging technology to ensure your
investment today will still be valuable tomorrow. The OMG will continue
to use Domain groups to define internal specific interfaces for those
looking to standardize on internal processes and integrate applications
within your business.
We will also begin to form specialized subgroups with a mission to
define the "Domain Public Interfaces" found between businesses
and other businesses (business-to-business) as well as between
businesses and customers / stakeholders (business-to-customer). This
will be much more of an external focus as opposed to the internal focus
found today in the domain groups.
The OMG will work with our members and other organizations that
control industry interfaces to define common interfaces for everyone to
use. One example might be an industry where there is a regulated
monopoly or an oligopoly where there is a need to define common
interfaces.
Influence to participate may need to come from not just the industry
businesses today found in the Platform and Domain groups, but from
customers of those businesses and stakeholders who also have a vested
interested in defining common, open interfaces. In fact, the days of
pressuring each of your vendors for custom solutions that meet your
changing business needs can be done more effectively through the OMG
process as a consolidated "voice of the customer" rather than
a single customer request.
Overall, our focus is to help members define architectures and
interfaces that will remain as the enabler of application integration
for the business-to-business and business-to-customer e-business models,
and the value chains of businesses.
Model
1 The OMG: Enabling e-Business throughout Value Chains
Model
2 The OMG: Intra and Inter-Company Domain Opportunities throughout Value
Chains
Model
3 The OMG in the Application Integration and Development Process
Note to editors: CORBA®, The Information Brokerage®, CORBA Academy®,
IIOP® and the Object Management Group logo® are registered trademarks
of the Object Management Group. OMG™, Object Management Group™, the
CORBA Logo™, ORB™, Object Request Broker™, the CORBA Academy logo™,
XMI™, MOF™, OMG Interface Definition Language™, IDL™,
CORBAservices™, CORBAfacilities™, CORBAmed™, CORBAnet™, UML®,
the UML Cube Logo®, and Unified Modeling Language™ are trademarks of
the Object Management Group. All other products or company names
mentioned are used for identification purposes only, and may be
trademarks of their respective owners.
Acknowledgement: Special thanks to the entire OMG team and Kevin
Tyson for reviewing this strategy paper and providing comments.
1 "Value Chain: The set of activities
an organization performs to create and distribute its goods and
services, including direct activities, such as procurement and
production, and indirect activities, such as human resources and
finance. Competitive advantage, according to Harvard Professor Michael
Porter, is achieved when an organization links the activities in its
value chain more cheaply or more expertly than do its competitors."
http://www.cio.com/archive/enterprise/051598_killer.html
2 By year-end 2003, the confluence of
product and pricing transparencies, sellers' increasing ability to
identify buyers through personalization databases and the increasing use
of extranet supply/value chains by sellers to gauge inventory,
production and demand will lead to acceptance of market pricing for all
goods sold on the Internet. (this web site is
under construction http://gartner4.gartnerweb.com/public/static/hotc/00077065.html
)
OMG - Strategic Approach to Value Chain Integration October 18, 1999
Prepared by: Wayne Haughey Version 1.0
Last updated on
11/09/2007 |
