The advantage of components is best explained through analogy; with automobiles, you don't have to understand how a starter works to use the ignition. Furthermore, parts suppliers make starters for different cars and it's not difficult to replace a starter. That is possible because the starters are standardized, and the interface (i.e., the ignition) is well known and isolates starting the car from other elements of the vehicle. It would be odd if turning on the radio used the same knob as starting the car.
The advantages of components are numerous. Component-based systems are more easily replaced, updated, and "rationalized," reducing the mass of systems that are functionally the same. Consider again the starter analogy. It's easy to replace a starter, and you don't have to replace the ignition to do so. You do not have to change the way you start your car when you replace the starter. Insurance components work exactly the same way, but our industry isn't (yet) as evolved as the automotive industry.
The first step towards this utopia is creating interfaces into the "back ends" of the components. A people component, for example, can have services to create, read, update, or delete parties within a customer relationship management (CRM) system. Creating a single interface for this component allows you to centralize, replace, and consolidate your people systems by establishing one way to gain access to person information.
Make no mistake, this is neither something that can happen overnight, nor is it simple. The challenges include:
- Separating user interfaces (UI) from the components;
- Service granularity complexity;
- Dealing with cross-component boundaries; and
- Employing the "three T's" to make something like this happen (see next page).
Separating the UI means rebuilding them, which is a huge investment. Service granularity involves understanding exactly what information services request and return; that's what we need to decide on as an industry. Component boundaries — for example, when parties are associated to policies — can be handled in many different ways, technically. Finally, the three T's are best summarized as:
- Talent – People who understand insurance, technology, and insurance components.
- Time – Isolating components is no easy task and takes time.
- Tolerance – We need to instill trust so the business can be patient and willing to spend the money.
As I mentioned in my last entry, not a lot of what I'm saying here is unknown. Vendors talk about it (albeit in proprietary ways), as do architects. Component architectures seldom see the light of day because of three T's failure and because, at this point, there isn't a standard representation of components.
Components aren't easy to create and implement for existing companies. However, it's about to become easier, and what companies get in return for creating components is significant: freedom to create, alter, and consolidate systems, enabling the agility to more rapidly meet the needs of business change.
For next time, I'll get off my component soapbox (momentarily) to talk about another one of my favorite topics – vendors. It's a symbiotic relationship, and there are things we can do to maximize them.
© Arc, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to TMSalesOperations@arc-network.com. For more information visit Asset & Logo Licensing.