Business processes went from
being explicitly defined to being built into the system-to-system handoffs. In
architecture, this is known as the Pipes and Filters pattern. System A does
some work and then hands it off to System B for the next step, which then passes
it to System C and so forth. However, as the functionality and capabilities of
each system in the process changed, the overall view and control of the original
business process was lost. In addition, integration standards had not developed
yet, and IT used "tight coupling" to connect two systems to each other. Tight
coupling is defined as changes in one system force changes in the connected
system. Now, as System A was modified, it might cause System B to be modified,
which might force System C to be modified and down the line. To complicate
matters further, the forced changes to System B or C may result in certain
functionality no longer working, requiring fixes to be made as well. Since each
interaction between different systems had unique and, in many cases, complex
interfaces, any change to a business process became over time very costly, very
time-laden and fraught with many unknown downstream issues. IT became the bottleneck
for any business project because of the path that had been chosen over time.

However, while IT was digging a
deep hole for itself and the business, it was also developing the solution to
restore the proper order. Tight coupling was recognized as a major stumbling
block. Therefore, many architectures were moving from tightly coupled systems
to loosely coupled systems, meaning that the interface between the two systems
became more functionally defined and the implementation details were abstracted
and standardized so each system could be updated, modified even replaced with
little to no impact to the connected systems. Eventually, this journey became
known as service-oriented architecture (SOA). While SOA received a lot of hype
as a solution that could provide value to the business in many ways—namely
through better agility, lower IT costs due to reuse and loosely coupled systems
and faster speed-to-market delivery—SOA is an IT solution, not a business one.
However, SOA enables the ownership of insurance business processes to be
transferred back to the business.

Business-oriented architecture (BOA) is a business approach whose main focus is the
business models and processes and is based on three main principles: implementation
independence, location independence and contract management.

Implementation independence was
one of the original tenets of SOA—the ability to design solutions without
having to know how they are actually implemented. Implementation independence
covers not only the language in which the system is written but also the
underlying infrastructure. The business should not have to know or care about how
IT has solved its business problem as long as it meets the business
requirements. Implementation independence also provides IT with great
flexibility as it implies that they could change any implementation details
about the system without impacting the overall business process. Why is this
good for IT? IT has been and will continue to be under great pressure to
provide less costly, more agile and higher performing solutions for the business.
If a new solution becomes available that allows for improvements on one or all
of these dimensions, IT should be free to provide these improvements with
minimal or no impact to the business processes that they are supporting. The
key point about implementation independence is the business can develop, modify
and maintain business processes in business terms and requirements without
regard to how the solutions are implemented. Never again should a businessperson
use a system name to refer to a business process.

Location independence allows the
business to be free of concern as to whether the system is onsite or off-site
or the details of either option. Location independence allows the business to
leverage an internal solution at one point in time and a cloud or software as a
service (SaaS) solution tomorrow. These are and should be IT solution details
and not that of the business. Again, the focus of the business should be on the
business models and processes, working with IT for the best solution but not
constrained by the location of the systems implementing the process. BOA does
not presuppose an externally developed or managed solution. Architectural
solutions must be designed so that the location of an application or service
can be moved, even in real time, without any impact to business processes.

Contract management begins with
business process accountability and is the management of the contracts with the
solution providers, both internally and externally. Insurers today have fairly
mature contract management processes for external solutions. They typically include
service-level agreements (SLAs), service-level objectives (SLOs), message
volume expectations and sometimes penalties for providers that do not meet
their SLAs. In addition, one or both parties will make sure that the SLAs are
monitored and alerts are sent out when thresholds are exceeded. Unfortunately,
most insurers do not have any form of contract management for internal
solutions, but these are just as important to allow business process owners
insight into and management of said business processes.

Business and IT together over
time transformed business process owners into IT system ownership. However, SOA
solutions have allowed IT to begin the process of migrating ownership back to
the business and the ability to truly support the business in meeting its
business goals and objectives—to enable business and IT to become true
partners. This would be to the benefit of both and enable the business to
incorporate emerging technologies and more easily modify and adapt their
business models to the consumers' and markets' changing requirements.

BEN MORELAND is a senior analyst in Celent's
insurance practice. For more, visit www.celent.com/analysts/benjamin-moreland.