Business-oriented architecture is bringing ownership
    back where it belongs—giving IT and the business independence to do what each
    does best.


    Over
    the last several decades in insurance, the business has handed over
    accountability of business processes to IT. It wasn't a conscious decision but
    one that evolved over time. Before computers, of course, all business processes
    were manual and the business fully owned and was accountable for them. With the
    advent of the mainframe, many of the business processes were automated on the
    monolithic system. IT's role was to solely support the business. Therefore, the business was
    still accountable and owned these business processes.


    As
    client/server systems evolved into distributed systems and N-Tier systems, many
    parts of the business processes were partially moved off of the mainframe onto
    middleware systems that allowed for greater agility. However,
    as parts of the insurance business process were implemented on different
    systems, ownership not only transferred from the business to IT, but insurers
    lost the notion of the "business owner" and, subsequently, the idea of "system
    owners"
    emerged. The business no longer owned its business processes and stopped
    speaking in terms of the process but in terms of system names. The new business
    submission process, for example, might be called NBS3 process, after the
    "system" on which it was implemented. Business could no longer easily change
    its business processes, as these were now IT-dependent.





    Click here to enlarge image»



    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.